You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 追記 RailsでJS辛い問題に関しての結論:http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptが
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した. “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて,ビジネスロジックに集中すること目的としている.Heroku特有なものではなく,一般にも十分適用できる知見となっている. 最近は,モバイル向けにAPIをつくることも多いため,勉強もかねて抄訳した.なお内容は,HTTP+JSONのAPIについて基本的な知識があることが前提となっている. 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと.例えば,“成功"を示すステータスコードは以下に従う. 200: GETやDELETE,PATCHリクエストが成功し,同時に処理が完了した場合 201: POSTリクエストが成功し,同時に処理が完了した場合 202: POSTやDELETE,PATCHリク
http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html 北米のインターネットトラフィックの30%以上を占めるNetflixのシステム構成は、UI(デスクトップ、スマホ、タブレット、ゲームコンソール、TV、ブルーレイ再生機)とサービス(Video meta data, search, user, A/B test, personalization)をAPIでつなぐアーキテクチャーになっていて、UIとサービスがそれぞれ独立して早いスピードで改善 & 新機能を投入できるかたちになっています。そのAPI改善から継続的デリバリーの仕組みをつくりあげるまでの昨年からの一連の動きを、4回にわけて紹介します。まず最初はAPIの改善の取組みから。 1) 背景 Web APIとしてはRESTが標準的になっている
http://techblog.netflix.com/2014/03/the-netflix-dynamic-scripting-platform.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約8時間前 Netflixはストリーミンングを配信するデバイスが800種に及ぶため、各デバイスを担当するクライアントチームのために社内向けAPIを用意しています。パブリックAPIのように全員一律の仕様を強要するかたちでは、デバイスごとの最適化が図れないため、各クライアントチームがエンドポイントをカスタマイズできるかたちになっています。こちらの図のように、サーバ側にあるクライアントアダプタのコードをクライアントチームが扱います。 今回は同社のAPIチームが、クライアントチームのために用意した開発環境について、詳
http://rubyrogues.com/147-rr-apis-that-dont-suck-with-michele-titolo/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。 1) Follow Conventions はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持し
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい(というか実用的)かど
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか? 一般的に、以下の2点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前2者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
HATEOAS (Hypermedia as the Engine of Application State) is a constraint of the REST application architecture. A hypermedia-driven site provides information to navigate the site's REST interfaces dynamically by including hypermedia links with the responses. This capability differs from that of SOA-based systems and WSDL-driven interfaces. With SOA, servers and clients usually must access a fixed sp
江島健太郎さんをゲストに迎えて、Satoshi Nakamoto、Mt. Gox、Macbook Pro、Digital Ocean、リモートワーク、API バージョニングなどについて話しました。 スポンサー: Ruby on Rails チュートリアル 0:00 miyagawa: Satoshi Nakamoto。 kenn: (笑)紛らわしい名前だよね。 miyagawa: 似たような名前の友だちとか結構いるんで紛らわしいんですけども。Newsweek が「こいつが Satoshi Nakamoto だ」って言って記事を出したんだけど。ロスアンゼルス郊外に住む67歳の日系アメリカ人ですか。 kenn: なんか見たことある感じの人だよね。 miyagawa: ちょっと見た目が「あれっ?」って感じなんだけど。鉄道オタクでね。昔政府系の組織でコントラクトをやっていて、数学に詳しくて、みたい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く