最近Webサービスを作ることになり、Web関連について復習しています。特によくRestfulと呼ばれるのが何を差しているか、理解があいまいになっているように思い、以下の本を読み返していました。
重要だと思ったところや、感じたところをメモしておきたいと思います。
RESTとRestful
REST技術とは次の6つを組み合わせたアーキテクチャスタイルのこと
- クライアント/サーバー ： UIと処理の分離
- ステートレスサーバー ： サーバー側でアプリケージョンの状態を持たない。AWSでもステートレスにする、と言われているのはこれか・・・
- キャッシュ： 通信回数を減らす
- 統一インタフェース： インタフェースを固定
- 階層化システム： システムを分離
- コードオンデマンド： プログラムをダウンロードしてクライアントで実行
Restfulというのは、上記の制約に従ってRESTらしいことを呼ぶ。
APIでもRestfulなAPI、REST APIと呼ばれるものはこれらの制約を満たしているということなのですね。
HTTP
ステートフルなやり取りと、ステートレスなやり取りがある。ステートフルなやり取りの例がFTP、ステートレスがHTTP。
アプリケーションがアプリケーション状態を持つ場合、これをセッション状態と呼んで、システムにログインしてからログアウトするまでの一連操作を示す。
HTTPメソッドは、GET、POST、PUT、DELETE、HEAD、OPTIONS、TRACE、CONNECTの8種類しかない。このうち、GET、POST、PUT、DELETEの４つでCRUD（Create, Read, Update, Delete)というデータ操作の基本処理を満たす。
- べき等性： ある動作を何回やっても結果が同じであること → PUT、DELETE
- 安全： 操作対象のリソースの状態を変化させないこと → GET
現実としては、ほとんどがGETとPOSTでまかなわれている。
レスポンスのステータスコード4xxと5xxはエラー。
HTTPヘッダで、キャッシュやリソースへのアクセス権を設定する認証を行う。HTTPヘッダの使用は、電子メールの仕様と似ている。
HTML、Atom、XML
HTML5が仕様策定中になっているなど、この辺は内容が既に古い・・・
JSON
JSONはAjax通信におけるデータフォーマットとして活用されてきた。
データ型は、オブジェクト、配列、文字列、数値、ブーリアン、nullの6通り。
読み出しのみのWebサービスの設計
リソース設計＝クライアントとサーバの間のインタフェースの設計どのようにリソースを分割し、URIで名前を付け、相互にリンクを持たせるか。
WebサービスとWebAPIの外部設計。これらを分けて考えないことが大切。
設計は、提供するデータを特定し、リソースに分け、リソースにURIで名前を付ける。クライアントから入力を受け取る場合はクエリパラメータを使用する。
そして、リンクトフォームを利用してリソース同士を結び付ける。
イベントの標準的なコースと、エラーについても検討する。
書き込み可能なWebサービスの設計
リソースの更新は基本的にPUTで行う。
複数のリソースにまたがる変更を扱うのがトランザクション。2つの処理が成功するか、失敗した場合は2つとも元に戻すことを保証する必要がある。
トランザクションリソースを使って、トランザクションリソースを取得してそこに対して一連の処理を実行する。リソースに対しては排他制御が必要になる。
リソースの設計の成果物は、
- 関係モデルのER図
- オブジェクト指向モデルのクラス図
- 情報アーキテクチャの3つ。
情報アーキテクチャはリソース設計と相性がいい。
最後に
RESTの考え方をどうやってWebサービスの設計に落とし込むかは、もう少し例を重ねて考える必要があると思った。
