Leonrd Richardson / RESTful Webサービス(isbn:9784873113531)

book

RESTful Webサービス

REST=HTTPの元々の仕組みに則ってWebサービスを作成すれば、もっとシンプルにできるという設計思想と判断しました。
具体的には、"URI"（=リソース）を適切な"統一インターフェイス"（=HTTPメソッド）で操作して、適切なステータスコードを返すようにするようです。

ROAの概念

  1. リソース
    • 「それに対してハイパーテキストリンクを作成する、それに対して意見または反論する、その表現を取得またはキャッシュする、あるいはその他の操作を実行する」ことがある場合は、それをリソースにすべきである。
    • リソース間の関連性、アルゴリズム、トランザクション等もリソースとして扱う。
  2. 名前(URI)
    • 利用可能なすべてのアイテムにラベルを付けるための簡単な手段
    • リソースは少なくともURIを1つ持っていなければならない。
    • 構造的であるべき
    • 予測可能であるべき
  3. 表現
    • リソースの状態に関する有益な情報
    • 特定の言語(ja, en, tr, ...)とか、特定のファイル形式(XML, JSON, ...)とか
  4. リソース間のリンク
    • リソース間の相互リンクで関連性を表す。

ROAの特性

  1. アドレス可能性(Addressability)
    • 提供可能な情報を1URIで記述できること。
      • HTTPヘッダに情報を書かない。クエリー推奨。
        • 例外として、URIが処理出来なくなるほど長くなる場合は、ヘッダ使っても良い。
    • どんな表現が欲しいかも、URIで指定可能にする。
  2. ステートレス性(Statelessness)
    • サーバー側はリソース状態のみを管理し、アプリケーション状態を管理しない。
    • アプリケーション状態はクライアントが管理するべき。
      • CookieにセッションIDを持たせるのは禁止！
      • クライアントがCookieを使ってアプリケーション状態を管理するのは、極めて妥当。
    • トランザクションはリソース
      • サーバーで管理すべき状態だから？
    • 認証はHTTPヘッダで
    • 部分GET
  3. 接続性(Connectedness)
    • リソース間の相互リンクで関連性を表す。
  4. 統一インターフェイス
    • GET：リソースを取得する。
      • 安全かつべき等であること（＝副作用がないこと）
    • POST：既存のリソース(URI)に対して従属リソース（子リソース）を作成する。
      • べき等であること
        • インクリメント禁止
    • PUT
      • 新しいURIへのPUT：新規リソースを作成する。
      • 既存のURIへのPUT：既存のリソースを変更する。
    • DELETE：既存のリソースを削除する。
    • HEAD：リソースのメタデータを取得する。
      • 安全かつべき等であること（＝副作用がないこと）
    • OPTIONS：特定のリソース(URI)がサポートするHTTPメソッドを調べる。
      • 安全かつべき等であること（＝副作用がないこと）
    • 現状はどうしようもないので、やむを得ずPOSTを使い、クエリーでメソッドを指定する(?_method=delete)