質問はTwitterへ #RESTudy をつけてどうぞ。
第11章〜第13章は、考え方としては役立ちますが、現在ほとんど使われていない記述があるので、後回しにしてまず第14章から読んでいきましょう。14章を読み終わったら、グループで話し合って第11章〜第13章の興味のあるところに進んでもらってかまいません。
JSONはJavaScript Object Notationの略で、RFC 4627が規定するデータ記述言語です。
現在は更新され、RFC7159で規定されています。ECMA-404でも規定されています。
JavaScriptの仕様となっていることもあり、JSONの数値はIEEE 754-2008 binary64 (浮動小数点数演算標準-倍精度) で実装されていることが多いので、その範囲外の 1E400 や 3.141592653589793238462643383279 などの JSON 数を使うと相互運用性の問題が生じるかもしれません。整数は [-(2**53)+1, (2**53)-1] の範囲以外は問題が生じるかもしれません。
Ajax で用いる XMLHttpRequest という JavaScript のモジュールは、セキュリティ上の制限から JavaScript ファイルを取得したのと同じサーバとしか通信できません。
とありますが、現在の多くのブラウザでは XMLHttpRequest Level 2 でCORSに対応したため、クロスドメイン通信が可能になっています。
web サーバーがサイトを跨ぐアクセスを制御する方法を規定することで、サイト間での安全な通信を保証するというものです。特筆すべき点として、この仕様は XMLHttpRequest のような API コンテナ内で緩和策として使用されることにより、現行のブラウザにおいて同一ドメイン制限を超えることを可能にするということです。
https://developer.mozilla.org/ja/docs/HTTP_access_control
ブラウザからJavaScriptで他のサーバにアクセスしようとしたとき、昔は同じドメインにしかアクセスできませんでした。（「クロスドメイン通信の制限」p.237を参照） CORSを使うと、 サーバが許可した場合 ブラウザは別ドメインのサーバへJavaScriptでアクセスすることができます。デフォルトでは不許可です。
サーバがブラウザへ許可を伝える方法はレスポンスヘッダですが、POSTのような安全でないメソッドの場合、レスポンスで許可／不許可を確認する前に、すでに安全でない操作が完了してしまいます。これではデフォルトで不許可になりません。
そこで、先にサーバの許可／不許可を確認するため、ブラウザは自動的にOPTIONSリクエストを送ります。これをプリフライト(preflight: 飛行前の)リクエストといいます。
この用途ではサーバはAllowヘッダではなくAccess-Control-Allow-Origin,Access-Control-Allow-Methodsヘッダなどを返します。
OPTIONS /resources/post-here/ HTTP/1.1
Host: other.example.jp
Origin: http://me.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Access-Control-Allow-Origin: http://me.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER
Access-Control-Max-Age: 1728000
...
許可されたので、この後ブラウザはPOSTリクエストを送ります。
Amazon S3にブラウザからJavaScriptで直接アップロードすることができます。
第11章 microformats はほとんど使われていません。
microformats では class 属性や rel 属性の値だけでメタデータを特定するため、もしたまたま同じ値の class 属性や rel 属性を持った Web ページがあっ た場合、プログラムが誤判定を起こしたり、同じ属性値を持った別の microformats が作れなくなったりするのです。
— 「Webを支える技術」p.184 より
この問題点をHTML5の専用属性を作ることで解決し、現在代わりに使われているのが Microdata です。また、あまり使われていませんが RDFaの複雑さを緩和した RDFa Lite もあります。
- Microdata を使ってみよう。サンプルソースで学ぶ Microdata | WWW WATCH
- 複数のVocabulary（語彙）をマークアップする点においてのMicrodataとRDFa（RDFa Lite） - E-riverstyle Vanguard
第12章 Atom は、RSSも含む「フィード」という枠組みでは少し使われています。コレクションリソースの考え方は設計のとき重要です。 12.5節「Atomの拡張」はOpenSearch以外はほとんど使われていません。
第13章 Atom Publishing Protocol は、一時期GoogleがAtomPubを拡張したGDataを多くのWeb APIに採用し、Microsoftも同様に拡張したODataを使用したりしていましたが、次第に単純なJSONのAPIに移っていき、今はほとんど使われていません。
http://www.slideshare.net/t_wada/restful-web-design-review
スライドを読んで、感じたこと、疑問点などをグループで話し合いましょう。 スライド中の用語に関して理解が不安なときは「Webを支える技術」のページを振り返ってみましょう。
リソースの GET/POST/PUT/DELETE と DBの SELECT/INSERT/UPDATE/DELETE は単純に対応させてしまいがちですが（とくにWeb APIの設計では注意）、「情報アーキテクチャからの導出」（Webを支える技術 p.305-）に沿って画面から考えると、従属的なテーブル、粒度の細かいテーブルはリソースに現れにくくなります。
例えば tagging テーブルに“自動的に”対応する taggings リソースを作ったとします。 /taggings, /taggings/1 のような画面は必要かどうかを考えてみましょう。
リソースの粒度/視点(つまりは URL)とデータベースの粒度/視点の違いを解釈してしかるべく結びつけるのが Controller の仕事
リソースはモデルに対応するのではなくコントローラに対応します。リソースとデータベースを直結するのは失敗の原因になります。
GET 重要。とても重要。
意外と無視されていることが多いですが、とても重要です。ブラウザにURLを入力してEnterを押すと、GETになります。つまりGETはデフォルトのメソッドです。POSTだけ有効でGETできないようなリソースを作ってはいけません。
POSTとPUTの違いは、Webを支える技術 p.95 を参考にしましょう。
POST でリソースを作成する場合、クライアントはリソースの URI を指定できません。URI の決定権はサーバ側にあります。逆に PUT でリソースを作成する場合、リソースの URI はクライアントが決定します。
_
どうにもならなくなったら POST に倒す
これはWebを支える技術 p.92 を参考にしましょう。 ただし「どうにもならなくなったら」は最終手段です。その前に、CRUDに当てはまらないと思えるような処理は、別のリソースに分けた方がうまくいくことが多いです。
HTTP メソッドでは実現できない機能があると感じたら、それが独立した別リソースで代替できないかを考える。検索機能を実現する SEARCH メソッドを HTTP に追加するのではなく、「検索結果リソース」を GET する、と考えることが重要である
— 「Webを支える技術」p.295 より
例：ユーザをグループに追加・グループから削除したい
POST /groups/1/add_user POST /groups/1/remove_user ?
POST /users/1/join_group POST /users/1/leave_group ?
membershipというリソースをつくることで
POST /memberships DELETE /memberships/3 とできる。
ここまでの内容は、@moroさんの「RESTful APIのみつけかた」もとても参考になります。
「Webを支える技術」も活用しましょう。