本記事の内容
Webを支える技術を読んだ際のノートのようなものです。
省略している部分もあり、書籍の内容を完全に要約するものではありません。
今回は第15〜16章あたりの内容です。
Webサービス設計？
システムの構成と開発手段を決める。
WebサービスとAPIを一体で考えることが良い設計のポイント。
設計とはバランスを取る作業。
なるべくシンプルに、困ったらリソースに立ち返って考える、いざとなればPOSTで何でもできるということを覚えておくとよい。
読み取り専用Webサービス設計
下記を大事にしながら設計すること。
- アドレサビリティ
- 接続性
- 統一インタフェース
- ステートレス性
キーワード的にはWebの重要な要素で出てきたものたち。
リソース指向アーキテクチャ
-
提供するデータの特定
-
データをリソースに分ける
機能からリソースに変換する感じ -
リソースにURIをつける
パスの階層でリソースの親子関係を表現する -
リソース表現を設計する
XMLなのか？JSONにするのか？
URIで拡張子指定をさせてあげるか？などなど -
リソース同士の結び付け
レスポンスにリンクを入れる -
イベントの標準コースを決める
ユーザーの一連の操作を考える -
エラーの設計
ざっくりまとめると
どういうデータを、どう分けて、どういうエンドポイントで提供する。
どういう表現で返して、その内容は何で…
という流れで考える感じ。
書き込み可能Webサービス設計
読み取り専用に比べて、書き込み操作がある分難しさが上がる。
下記のような点を考慮する必要がある。
- 操作がバッティングしたらどうするのか
- 複数リソースの操作はどうするか
- 複数の操作手順のかたまりをどうするか
リソース作成
下記の２パターンがある。
- ファクトリリソースのPOST
- 直接PUT
- 更新との区別をしなくていいのは楽
- URIの仕様をクライアント側が守る必要が生まれる
リソース更新
- Bulk Update
- 更新しない要素も含め全てを送信する
- 通信量が膨大になりがち
- Partial Update
- 一部だけを送信する
PUTだとリソースをURIで指定するので、一般的にはPOSTで行う。
バッチ
途中で失敗した場合はステータスコード207。
または200を返しておいてBodyなどで独自に内容を返却する。
トランザクション
RESTfulにするにはトランザクションリソースが重要。
リソース状態とセッション状態は別なので、分けて考えよう。
排他制御
操作がバッティングしたときにのためにリソースに対してロックをかけたりするが、悲観的ロックと楽観的ロックがある。
悲観的ロック
ユーザーを信用しない姿勢。
ステータスコードは423 Lockedを返却する。
楽観的ロック
競合したときに考える姿勢。
条件付きPUT/DELETEを使って、変更されてなかったらやるスタイル。
変更されていなければ、ステータスコード412 Precondition Failedを返却する。