RESTful Webサービス

2007年出版のRESTに関する本。
RESTの概念。RESTfulなサービスとはなにか、現状でRESTの概念にそっているシステムや
RESTにみえているけど、そうでない場合の解説。
そうでないシステムをRESTfulにするための方法解説。
RESTfulなシステムの設計と実装の例
用語URI＝URLのことと思っていいらしい。

Webは分散プログラミンのプラットフォーム。その仕組みは単純シンプルであるべき。
いまやWebサイト＝Webサービスといってもいい。
COMやCORBAは重く、Webプログラミングの流れを阻害する。
WebはHTTPプロトコルというリクエストされたもののアドレスを返すというシンプルな仕組みで動いている。
そのプログラミングもシンプルであるべき。


プログラマブルWebの例を示すために、AmazonのS3で検索する操作などを解説。
HTTPでリクエストをうけて、データをXMLで提供する。
ただし、RESTならデータはROA（Resource-Oriented-Architecture)になる。
例はAtom　Publidhing　Protocol

大Webサービス＝WSDLやSOAP
上記はHTTPとURIを使ってはいるが、データを扱うときに手続き指向なので、RESTではない。
新しいツールは複雑さを隠ぺいできるが、その正当性を証明することはできず、常に複雑さが増す。
いろんなWebサービスを統合して使いたいときとかに困るってことかな？

いろんなサービス（Ruby Railsやdel.icio.us）のレスポンス解説。


RESTという概念は、Webサービスの潜在能力を引き出すためのシンプルなガイドライン
RESTはアーキティクチャではない、アーキティクチャを検証するための手段。
HTTP、XML,URIを使用。シンプルなインターフェースでWebサービスからデータを引き出す。
特徴
アドレス可能性・・・すべてのリソースは独自の一意なURIを持つ。表現はアドレス可能でなければならない。サーバーがどのデータを送るかはURIに含まれる（スコープ情報）
アドレス可能性は、サービスの提供者が思いもしない利用方法を提供する可能性を示す。

状態とステートレス性・・・状態は２つ、リソースに関する情報を表すリソース状態（サーバー管理）と、アプリケーションにおいてクライアントがたどる経路に関する情報のみを表すアプリケーション状態（クライアント管理）。お互いの状態を知る必要がある場合は、状態を送信する。
ステートレス性によって、一つ一つのリクエストが独立するので、アプリケーションの拡張が容易になる。

接続性・・・リンクとフォームはリソースを相互接続する。サーバはリンクとファームを表現として送信することで、クライアントのアプリケーション状態を、ある状態からある状態に遷移することができる。
今のリンクは次のURIを構築する方法を文章で説明するという状況。リソースが相互に接続されることによって、クライアントがURIからURIへナビゲートするのがスムーズになる。

統一インターフェース・・・クライアントとリソースの間のやり取りは、いくつかの基本的なHTTPメソッドによって処理される。どのリソースもこれらメソッドの一部またはすべてをサポートし、メソッドはそれらをサポートするどのリソースでも同じように機能する。HTTPのもっとも一般的な４つの操作はGET,POST、PUT、DELETE
POSTについては誤解が多い、POSTの機能は実行されるサーバで決定する。RESTfulな設計ではPOSTは従属リソースを作成するために使用される。

例としてはAmazonのS3があがっていることが多かった。比較するRPCの例はdel.icio.us
RPCは内部アルゴリズムを持つことがRESTではない。


ROAはクライアントが使いやすいWebサービスを設計するのに適したアーキティクチャ。
リソースとはそれ自体を参照するに値するほどの重要性をもつもの。通常はドキュメント、データベースの行、アルゴリズムを実行した結果などの一連のビットで表せるもの。少なくとも一つのURIを持つ。
URIは構造的であるべき。(予測可能）
表現・・・アプリケーションをリソースに分割すると表面積が増える。Webサービスはリソースを特定のファイル形式と特定の言語で送信しなければならない、それが表現。表現の選択の一つにコンテンツネゴシエーションがある。
リソース間のリンク・・・完全にRESTfulなサービスはリソースは意味のある方法で相互リンクされている。

ROAの一般的手順
①データセットを特定
②データセットをリソースに分ける
　各種リソースに対して、
③リソースにURIで名前をつける
④統一インターフェースのサブセットを提供
⑤クライアントから受け取る表現（一つ以上）を設計
⑥クライアントに提供する表現（一つ以上）を設計
⑦ハイパーメディアリンクとフォームを使用して、このリソースを既存のリソースに統合する。
⑧イベントの標準的な流れについて検討する
⑨エラー状況について検討する。



RESTfulなサービスの設計方法解説
読み取り専用のリソース指向サービスの設計（地図情報システムを例として）
①リソース設計
②データセット特定
③データセットをリソースに分ける
　こうしてできた５つのリソースタイプ
　　１　惑星のリスト
　　２　名前によって識別される惑星上の場所（あるいは惑星全体）
　　３　経緯度によって識別される惑星上の場所のリスト
　　４　特定の地点を中心とした惑星の地図
⑤リソースに名前をつける
　名前付けの３つの基本ルール
　１パス変数を使用して、階層をエンコードする。(Parent/child)
　２パス変数に句読文字を挿入して、存在しない階層の暗示をさける(/parent/child1;child2)
　３クエリ変数を使用して、アルゴリズムへの入力を示す。(/serch?q=jellyfish&start=20)
⑥表現の設計
　リソースの状態の表現、他の状態にリンクする表現・・・・など
⑦リソースの相互リンク
⑧HTTPレスポンス、予想される操作とエラー


読み取り/書き込み可能なリソース指向サービスの設計（地図情報システムを例として）
上記システムに＋してクライアントのためにデータを格納する機能をつける。

ユーザーアカウントを設計する
①リソースとしてユーザアカウントを設計
②ユーザアカウントの認証、認可、プライバシー、信用を設計
③要件に基づき読み取り/書き込み可能なリソースを作成
④データセット特定
⑤データセットをリソースに分ける
⑥リソースにURIで名前をつける
⑦統一インターフェイスのサブセットを提供
⑧クライアントから受信する表現を設計
⑨クライアントに提供する表現を設計
⑩このリソースを既存のリソース（地図）に統合する。
⑪期待される動作、予想されるエラー


サービスの実装
del.icio.usをRESTfulに実装しなおす例。
実装手段としてRuby　Railsを使用する。
del.icio.us・・・ブックマークを公開し、短いメタデータ文字列でタグをつけ、他人が投稿したURIを参照する


RESTとROAを使ったベストな設計の例
①リソースの設計
　リソース間の関係、非同期処理、一括処理、トランザクション、迷ったらリソースにする
②URI設計　意味のあるもので、十分に構造化されている必要がある。
③出力表現
④入力表現
⑤サービスのバージョン管理
⑥永続的なURIと読み取り可能なURI
⑦HTTPの標準機能
　認証と認可、圧縮、条件付きGET、キャッシュ、石橋をたたいて渡るリクエスト、部分GET
⑧PUTとDELETEの偽造
⑨Cookieの問題・・・これはステートレス性の原則に反する。
⑨ユーザはなぜHTTPクライアントを信頼するのか


HTTP、URI,XMLの基本テクノロジを使用した他のサービスについて
表現フォーマット・・・XHTML、Atomなど
パッケージ済みの制御フロー・・・一般規則、データベース連動の制御フローなど
ハイパーメディアテクノロジ・・・リンクとファームの2種類あり、URI TemplateやHTML4など

RPCスタイルの大Webサービスの解説と、それをRESTfulにするための設計のヒント。

RESTクライアントとしてのAjaxアプリケーション解説。
Ajaxアプリケーション・・・Webブラウザ内で実行されるWebサービスクライアント。
利点もあるが、ブラウザごとにコードが違うとかセキュリティ問題とかある。

RESTfulサービスのためのフレームワーク解説
Ruby on Rails
Restlet
Django

付録
参考文献
HTTPレスポンスの良く使用されるコード４２
よくしようされるHTTPヘッダー

RESTful Webサービス

• 作者: Leonard Richardson
• 出版社/メーカー: オライリー・ジャパン
• 発売日: 2007/12/21
• メディア: 単行本