「Webを支える技術」を読みました とRESTのまとめ
読み終わったので感想を書きます。
なぜ読んだか
随所でおすすめされている書籍だったことと大学図書館にあったから。また、RESTについて書かれているものを読みたかったため。
感想
Webに関する幅広い事柄について触れられました。最初期のインターネットのことから、REST, HTTP, URI, ハイパーメディアフォーマット（HTML, microformats, Atom, AtomPub, JSON）、そして実際のリソース設計まで。（miroformats, Atom, AtomPubの項は読み飛ばしちゃいました。）1周しかしてない上、このエントリーを書いてる時にはもう返却しちゃって、詳しいことは少し飛んでるけどそれでもWebの開発側の概観というものが分かった気がする。あと、嬉しかったのがJSONについて書かれていたこと。JSONって言葉よく聞くけど扱ったこともなく、いまいち知らなかったんですよねー。詳しいことで言えば、第16章 書き込み可能なWebサービスの設計での「悲観的ロック・楽観的ロック」もためになりました。1つのデータに対して複数人が書き込んだとき、誰の書き込みを採用するか、差分はどうするのかって話。
とにかく、300ページほどの本書ですが（プラス100ページほどHTTPステータスコードの説明などのおまけがあります）、図も多くかなり読みやすいので、内容に興味のある方はぜひおすすめです。
結局 RESTって？
REST（レスト）っていうのは、Roy Fieldingが提唱した今ホットなWebアプリケーション構造のパターンです。他にもWeb向けアーキテクチャパターンにはSOAPというものがあり、こちらは拡張性に優れているんですが、より扱いやすいRESTが主流になっていると書かれてました。
ちなみに読む前までは「RESTとRESTfulって何が違うの」って思ってたんですけど、解消しました。RESTという設計思想に則ったアーキテクチャをRESTfulと言うそうです。
RESTの原則
RESTは以下の4つの原則からなります。
Representational State Transfer - Wikipedia
- ステートレスなクライアント/サーバプロトコル
- すべての情報 (リソース) に適用できる「よく定義された操作」のセット
- リソースを一意に識別する「汎用的な構文」
- アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
どういうことか！
ステートレスなクライアント/サーバプロトコル
サーバーはクライアントの状態を保持せずに、クライアントは毎度毎度送信する情報にすべてのやりとりを含めるということです。
すっげーいい例を出します。
とあるハンバーガーショップにて。
ステートフル（ステートレスの逆）
店員「いらっしゃい」
客「ハンバーガーセット1つ」
店員「OK サイドメニューはどうする？」
客「ポテトMで」
店員「OK ドリンクはどうする？」
客「コーラMで」
店員「OK かしこまりました」
ステートレス
店員「いらっしゃい」
客「ハンバーガーセットで」
店員「OK サイドメニューはどうする？」
客「ハンバーガーセットのポテトMで」
店員「OK ドリンクはどうする？」
客「ハンバーガーセットのポテトMとコーラMで」
店員「OK かしこまりました」
（この例は本書で紹介してありました、内容は簡単にしてます。）
すごくめんどくさいこれがステートレスです。ステートフルの方が一回に送信するデータ量も少なくていいじゃないか！そう見えますが、ステートレスにもメリットはちゃんとあります。
例はハンバーガーショップだったけど実際はサーバーとのやりとり。ある程度の規模のものになってくるとサーバーが何台もあって、同一サーバと常にやりとりしているわけではありません。となってくると、ステートレスでは毎回毎回、処理の内容を全て送信しているわけですから、（ハンバーガーショップの話で言えば）店員さんが注文の追加のたびに入れ替わってもちゃんと注文ができるんですね。サーバ一台の小規模サービスなら、ともかくスケールの大きいものとなってくると必須の規則なのではないでしょうか。
すべての情報 (リソース) に適用できる「よく定義された操作」のセット
HTTPメソッド8つの中から特によく使われる4つのメソッド
- GET
- POST
- PUT
- DELETE
これをちゃんと意識しようね、っていうお話。
GETは普段から行ってるWebページ, 画像などリソースの受信。
POSTはリソースの作成。
PUTはリソースの更新ですが、作成もできます（非推奨）。
DELETEはリソースの削除。
リソースってのは識別できる情報なんでものことです。
PUTを扱う上での注意点があったのだけど忘れちゃったから引用。（もう1回読む必要あるね。）
しかし、リソースの新規作成はPUTメソッドでやらないほうが良いです。RFC2616 9.6項に「PUTメソッドで作成されたリソースの URI は、クライアントが指定した URI とする。サーバで URI を決めるべきではない」という規則があります。そして、RESTには「サーバの URI がどのように組み立てられているか、クライアントは知らなくて良いようにする」という思想があります。PUTメソッド でリソースを作成する場合、URI はクライアントが決めることになるので、クライアントがサーバの URI の管理方法を知らなければいけません。POSTメソッドであれば、作成されるリソースの URI をクライアントが意識する必要がなくなります。リソースを作成するときはPOSTメソッドを使ったほうが良いです。
http://shindolog.hatenablog.com/entry/2012/12/10/193000
リソースを一意に識別する「汎用的な構文」
RESTにおいて、すべてのリソースはURIで識別するよ。っていう話。「URIとURLの違いがわからないよ」という人は以下を見ましょう。
URLとURIの違いとは？ パーツの構造・名称・意味も大解説！ | 初代編集長ブログ―安田英久 | Web担当者Forum
RESTでは、どんなページどんな画像にもURIがあるってことでいいのかな（？） 今では当たり前のこと過ぎていまいちピンとこない。
アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
現在のアプリケーションの状態を表示できて、違う状態に遷移することができるハイパーメディアフォーマットを使おうよ、っていう話。ハイパーメディアフォーマットっていうのはHTMLやXMLのこと。（本書ではHTML, microformat, ATOM, JSONが紹介されている。）ハイパーメディアフォーマットっていうのは、テキストのみならず画像や動画、音楽、さらには別のページへのリンクが記せる媒体のこと。今見てるページがそう。html。
まあこれ、ハイパーメディアフォーマットを扱うのがRESTだよ、と。
あと私的に気になっていたJSONについて。
JSONとは
JSONっていうのはJavaScriptの記法でデータを表現できる形式です。ならJavaScriptでしか扱えないのか、というとそうではなくけっこうなプログラミング言語が対応してます（濁した表現。何は使えないか、とか詳しいことは知らない。扱ったことないもん）。JSONはよりプログラミング言語向きなデータ構造でありながら、人間にもわかりやすい記法である、というメリットがあります。
あと、JSONはハイパーメディアフォーマットということですが、動画像などメディアを扱う場合は、リンクを使用します。
Ajaxでは必須となってるそうですが、その他の利用シーンについて知らないので、そのへんはわかったらエントリーにします。
というわけで
RESTってなかなか謎だったんですが浅く解明。他にもHTTPやリソースなんかも。RESTを実際に設計に落としこんでいくには、どんどん開発していくのみだと思います。また、なんでもかんでもRESTだ！ RESTful！ じゃなくて、サービスに合わせて適材適所取り入れていくのが開発者としての腕の見せ所でしょうか。RESTRESTREST。
「Webを支える技術」いい本でした。おすすめ。
