Webを支える技術 第16章 書き込み可能なWebサービスの設計 その2

• バッチ処理
  • 通信のオーバヘッド軽減のために複数の要求を JSON などでデータとしてまとめて投げる
  • エラーが発生した場合の戦略
    • トランザクションにする。どこかでエラーが置きたら全ての要求は失敗(更新しない)
    • エラーになったのがどの要求か返す
      • 207 Multistatus を返して WebDav の 要素(XML)で内容を返す
      • 200 OK を返して独自のフォーマーットでエラー内容を返す(JSON など)
• トランザクションをRESTfulに
  • トランザクションリソースを導入
    • トランザクションファクトリリソースからトランザクションリソースを生成
    • トランザクションリソースへ更新要求を追加していく(追加しているだけで更新するわけではない)
    • トランザクションリソースへトランザクション実行を要求すると一括更新される
    • トランザクションリソースの削除
      • トランザクションの実行でトランザクションリソースが削除されるようにしてもいいような気がするのですがどうなんでしょう
    • 状態をセッション情報としてでなくリソースの状態として持つ
    • 生成したまま放置されたトランザクションリソースをタイムアウトなどで開放する実装も必要?
  • バッチ処理の実装をトランザクション化する方法も
  • 上位リソース(/entry/1)を削除すると下位リソース(/entry/1/comment/1)も同時に削除する、というようなリソースの依存関係に基づく一括操作もある
• 排他制御
  • 複数のクライアントが同じリソースにアクセスするのを防ぐ
  • 悲観的ロック
    • WebDav の LOCK, UNLOCK メソッドによるリクエスト
      • タイムアウト、共有ロック/排他的ロックの種類の指定などができる
      • ロックトークンが返されるので、それ以降対象のリソースの更新はロックトークンをIfヘッダで渡さないと失敗する(423 Locked)
    • ロックリソースの導入
      • トランザクションリソースの時と似てる。ロックリソースを作成して対象のリソースを更新する。独自に定義できるのでユーザ情報でロック取得者を認識させることもできる(しトークンを使ってもいいと思う)
  • 楽観的ロック
    • 条件付きPUTで「Conflict が起きた時だけそれを検出して再試行を促す」というやりかた
    • If-Modified-Since, If-Unmodified-Scince, If-Match, If-None-Match などのヘッダで更新があった時に失敗させる
    • 競合したら 412 Precondition Failed を返す
• 設計のコツ
  • KISS (Keep It Simple, Stupid)
  • 困ったらリソースで解決。新しいメソッドが欲しいなぁ→それを表現するリソースを導入してみる
  • POST の活用を躊躇わない。本当に必要なら

第16章はこれで終わりです。