RESTful Webサービス メモ

今やっている仕事の関係で、RESTful Webサービスを買ったのでそのメモ。

RESTful Webサービス

全般メモ

• RESTは、ウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつである。初めはアーキテクチャの原則と制約の集まり(後述)を指していたが、次第に、XMLやHTTPを使った簡易なウェブベースのインターフェイスのうち、WebサービスのSOAPプロトコルのような MEP（Message Exchange Pattern; SOAPノード相互のメッセージ交換のパターンを確立するための雛型）ベースの特別な抽象化をしないもののことを、大まかに意味する用語として使われるようになった。

• RPC（英: remote procedure call、リモートプロシージャコール）とは、プログラムから別のアドレス空間（通常、共有ネットワーク上の別のコンピュータ上）にあるサブルーチンや手続きを実行することを可能にする技術。

• SOAP（ソープ）は、ソフトウェア同士がメッセージ（オブジェクト）を交換する（リモートプロシージャコール - 遠隔手続呼び出し）ためのプロトコル。ここでいうオブジェクトとはオブジェクト指向のそれである。元はSimple Object Access Protocolの意味だったが、現在は何かの頭字語(略語)ではないとされている。

第3章 RESTfulサービスの特徴

• RESTful サービスは、リソースと呼ばれる標準HTTPオブジェクトを提供する
  • オブジェクトの値を取得するにはGET
  • オブジェクトのメタデータのみを取得するにはHEAD
  • バケットを作成するにはPUT
  • バケットまたはオブジェクトを削除するにはDELETE

• 適切に設計されたRESTfulサービスでは、全てが名前のとおりに機能する

• Restfulアーキテクチャを定義づけるもう一つの特徴は、HTTPレスポンスコードの使用である
  • 400(Bad Request)：クライアントが送信したデータをサーバが理解できないことを示す
  • 409(Conflict)：データが含まれているバケットをクライアントが削除しようとしたときに送信される
  • 日常的に使用する上で重要なレスポンスコードは10個ほど

• オブジェクトへのアクセスの権限（アクセスポリシー）
  • S3では以下の4つ
    • private：秘密鍵で署名されたリクエストのみ受理
    • public-read：署名されていないGETリクエストを受理
    • public-write：署名されていないGET、PUTリクエストを受理
    • authenticated-read：署名されていないリクエストを拒否するが、読み取りリクエストに他のS3ユーザーの秘密鍵で署名可能。

第4章 リソース指向アーキテクチャ(ROA)

• RESTを定義づける2つの原理
  • アドレス可能性の原理：スコープ情報（サーバーがどのデータを送信するか）はURIに含まれる
  • 統一インターフェイスの原理：メソッド情報（サーバーがデータをどのように処理するか）はHTTPメソッドに含まれる

• リソースとは、それ自体を参照するに値するほどの重要性を持つもの
  • 少なくともURIを1つ持っていなければならない。(URI：リソースの名前とアドレス)
  • リソースはURIを1つ以上持つことが出来るが、すべてのURIはただ1つのリソースを表す

• URIは構造的でなければならず、その構造は予測可能な方法で区別される必要がある

• アドレス可能性
  • アプリケーションがそのデータセットの重要な部分をリソースとして公開する場合、そのアプリケーションはアドレス可能である

• ステートレス性
  • ステートレス性とは、全てのHTTPリクエストが完全に分離していることを意味する

• アプリケーション状態とリソース状態
  • 前者はクライアント側で維持される状態、後者はサーバ側で維持される状態
  • リソース状態は全てのクライアントで同じで、サーバに格納するのが正しい

• 統一インターフェイス
  • 4つの基本メソッド
    • HTTP GET：リソースの表現を取得
    • 新たなURIへのHTTP PUT or 既存のURIへのHTTP POST：新しいリソースの作成
    • 既存のURIへのHTTP PUT：既存のリソースの変更
    • HTTP DELETE：既存のリソースの削除
  • 3つのoptionalなHTTPメソッド
    • HTTP HEAD：メタデータ固有の表現を取得。リソースのメタデータのみを取得するため、エンティティボディは含まれない。
    • HTTP OPTIONS：特定のリソースがサポートするHTTPメソッドを調べる

• POSTの役割
  • 既存のリソースの注釈
  • フォーム送信の結果などの、データ処理プロセスへのデータブロックの提供
  • アペンド処理を通じたデータベースの拡張

• 安全性と冪等性
  • クライアントは未知のURIに対してGET, HEADリクエストを送信しても害はない
    • GET, HEADは正しく使用すれば安全
  • 1つのリクエストの実行が同じリクエストを繰り返し実行することと同じである場合
  • GET, HEAD, PUT, DELETEは冪等
  • DELETEは何度やっても同じ結果（特定のリソースを削除する、２回目以降は特に変化がないので）

• 統一性
  • すべてのサービスがHTTPのインターフェイスを同じ方法で使用することが重要