OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
CROSS2014の次世代Webセッションを見て来た。 セッションの前半で議論されていたプロトコル編はしっかりとした方向性が示されていたが、後半のアーキテクチャー編は現状の混沌とした話が多くて、方向性というか新しいビジョンを示すまではいけなかった印象だった。 それは、サーバのアーキテクチャーが成熟していることも理由の一つなのかもしれない。 しかし、アーキテクチャーこそ方向性を示すのが重要だろうと思うので、個人的に考えていることをまとめることにした。 Webスケールを実現する技術とリアルタイムWebの方向性 リアルタイムWebというわけではないが、密結合なプロトコルはことごとくインターネットで玉砕されてきた歴史がある。 古くはCORBA IIOP、DCOMの失敗。それからSOAPの失敗。 （ちなみに、IIOPのIはInternetで、当初は大規模なインターネットスケールで分散させようとしたこ
移転しました http://please-sleep.cou929.nu/20130121.html
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
RESTfulなWebサービスにおいて「指定したIDでリソースを新規作成するか、既に存在するのであればエラーとしたい」という場合どうするのが一般的でしょうか。 といった受け答えをしたい場合です。 以下のようなものを考え、それぞれ疑問点を付記しました。 1. POST /user/foo RFC2616 によると「新しい従属{subordinate} として、リクエストに同封されるエンティティを受け入れる事を要求する」とあり、新規作成はコレクションリソース (この場合 users) にすべきなのでしょうか。 2. POST /users (POSTパラメータとしてid=foo) そもそもPOSTで作成するリソースのIDを指定してもいいのでしょうか。 3. PUT /user/foo 重複IDをエラーとするので、リソースを更新できないことになってしまいます。 4. PUT /user/foo?
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.com: The REST API Design Handbook (English Edition): Reese, George (著), Reilly, Christian (はしがき): Digital Ebook Purchas