JavaによるRESTfulシステム構築(2) ~RESTfulサービスの設計~
目的
- RESTfulな分散システム構築の勉強がしたい
- Restの実現方法の1例を学習したい
- Javaに触れてみる
概要
- 架空のEコマースWebストアを設定し、簡単なオーダーエントリーシステムに対応するRESTfulインタフェースを定義してみる
- オブジェクトモデルをチェック
- 分散IFを追加
- URI定義
- データフォーマットの定義
- HTTPメソッドの設計
オブジェクトモデル
- ユーザー機能駆動等でオブジェクトを列挙したい
- Order
- Customer
- LineItem
- Product
URIのモデル化
- 分散IFを作成するためには、システム内に分散する各エンドポイントを定義することが必要。
- RESTfulでは通常エンドポイントをリソースと呼び、URIを使って表現する。
- 例
- /orders
- /orders/{id}
- /products
- /products/{id}
- /customers
- /customers/{id}
- URI設計について
- URIはミニRPCメカニズムとして使用されるべきではなく、各操作(関数)を示すべきではない
- HTTPメソッドとデータ構造を組み合わせて、分散RESTfulシステムの操作が一意に鳴るように設計すべき
データフォーマットの定義
- ネットワーク経由でクライアントに送るリソースを決める必要がある。
- 通常はschemaでデータ構造を定義し、そのデータ構造にあったデータをやり取りする。
選択肢
HTTPメソッドの割当
- 個々のリソースに公開するHTTPメソッドと、その役割を定義する。
- 必要十分な機能を各リソースに割り当てるために必要である
全オーダー、全顧客、全製品の参照
- リソース
- /orders
- /products
- /customers
- GET
GET /products HTTP/1.1
GET /products?startIndex=o&size=5 HTTP/1.1
各オーダー別、各顧客別、各製品別のデータ取得
- リソース
- /orders/{id}
- /products/{id}
- /customers/{id}
- GET
GET /orders/232 HTTP/1.1
オーダー、顧客、製品の作成
PUT
- リソース
- /orders/{id}
- /products/{id}
- /customers/{id}
- PUT
PUT /orders/233 HTTP/1.1
POST
- リソース
- /orders
- /products
- /customers
- POST
POST /orders HTTP/1.1 Content-Type: application/xml <order> <total>199.02</total> ... </order>
オーダー、顧客、製品の削除
- DELETEを使う
オーダーのキャンセル
DELETEの意味のオーバーロード(あんまりよくない)
- リソース
- /orders
- DELETE
DELETE /orders/233?cancel=true
状態と操作
- ある操作がリソースの状態である場合、その状態をデータフォーマット内に定義するべき
PUT /orders/233 HTTP/1.1 Content-Type: application/xml <order> <total>199.02</total> <cancelled>true</cancelled> ... </order>
- cancelledのデータを一掃する
POST /orders/purge HTTP/1.1
keyword
- エントリーポイント
エントリーポイントとは、プログラムを実行するうえで、プログラムやサブルーチンの実行を開始する場所のこと。プログラム全体のエントリーポイントとなる場所を含むルーチンがメインルーチンである。C言語の標準では、mainという名前の関数(の先頭)がエントリーポイントであり、各関数のエントリーポイントは、それぞれの関数の先頭である。
- エンドポイント
- エンドポイント、というのは「きわ」という意味。クライアント側とサーバ側の境界線のところがエンドポイント。