なおこの本では RESTful = ROA ではなく、ROA はあくまでも RESTful なアーキテクチャのひとつの実現形態、という位置づけ。"RESTはアーキテクチャでなく、一連の設計条件である。あるアーキテクチャがRESTの条件をほかのアーキテクチャよりも多く満たしていると表現することは可能だが、「RESTアーキテクチャ」というものは存在しない。(P84)" うーん哲学的。
「URI」について。
- リソースがリソースであるための条件は何か。リソースは少なくともURIを１つ持っていなければならない。(P86)
- リソースとそのURIを直感的に対応させること (P87)
- URIは構造的でなければならない。それらの構造は予測可能な方法で区別されなければならない。(P87)
- リソースはURIを１つ以上持つことができる。（略）すべてのURIはただ１つのリソースを表す。(P88)
「アドレス可能性」について。
- アプリケーションがそのデータセットの重要な部分をリソースとして公開する場合、そのアプリケーションはアドレス可能である。リソースはURIを通じて提供されるため、アドレス可能なアプリケーションは提供可能な情報ごとにURIを提供する。(P89)
「ステートレス性」について。
- ステートレス性とは、すべてのHTTPリクエストが完全に分離していることを意味する。(P91)
- ステートレスアプリケーションは、負荷分散サーバー間で簡単に分散させることができる。(P93)
- クライアント側で維持されるアプリケーション状態と、サーバー上で維持されるリソース状態とを区別する。（略）それらのクライアントに格納されるアプリケーション状態はそれぞれ異なる。（略）リソース状態は、すべてのクライアントで同じであり、サーバーに格納するのが正しい。(P95)
「リンクと接続性」について。
- リソースをそれらの表現において相互にリンクすべきだ （略）従来のWebが使いやすいのは、適切に接続されているからだ。（略）だが、ほとんどのWebサービスは、相互接続はおろか、内部的にも接続されていない。(P100)
「統一インタフェース」について。
- Web全体にわたって、リソースに対する操作は、ほんのわずかな基本的なものに限られる。
- HTTP GET: リソースの表現を取得する
- 新しいURIへのHTTP PUT、または既存のURIへのHTTP POST: 新しいリソースを作成する。
- 既存のURIへのHTTP PUT: 既存のリソースを変更する
- HTTP DELETE: 既存のリソースを削除する
- HTTP HEAD: メタデータ固有の表現を取得する。
- HTTP OPTIOS: 特定のリソースがサポートするHTTPメソッドを調べる
- HTTP GET: リソースの表現を取得する
- クライアントは、新しいリソースのURIをクライアントが決定する場合にPUTを使用し、新しいリソースのURIをサーバーは決定する場合にPOSTを使用する。(P104)
- GET, PUT, およびその他は、決して完璧なインターフェイスではない。重要なのは、すべてのサービスがHTTPのインターフェイスを同じ方法で使用すること、すなわち統一性である。(P109)
- 独自のHTTPメソッドを開発するのがとても危険な考えであるのは、このためである。独自のメソッドを使用すれば、たった１人のコミュニティで孤立することになる。
ついでに、"６章 読み取り／書き込み可能なリソース指向サービスの設計" から、リソースの設計手順(P152)をメモ。
- データセットを特定する
- データセットをリソースに分ける。各種リソースに対して、
- リソースにURIで名前を付ける
- 統一インターフェイスのサブセットを提供する
- クライアントから受信する表現（１つ以上）を設計する
- クライアントに提供する表現（１つ以上）を設計する
- ハイパーメディアリンクとフォームを使用して、このリソースを既存のリソースに統合する
- リソースにURIで名前を付ける
- イベントの標準的な流れについて検討する: 何が起きるはずか
- エラー状況について検討する: どのようなエラーが発生し得るか
0 件のコメント:
コメントを投稿