こんにちは。
リモートワークで運動不足が顕著に表れ、この期間でちゃんと太りました。
はじめに
先輩エンジニアから勧めてもらった「Webを支える技術 -HTTP、URI、HTML、そしてREST」を読んだのでアウトプットとして要点をまとめてみました。
今回は最終第5部のまとめになります。
1部〜4部についてもまとめておりますので、ぜひそちらもご参考にして頂ければと思います。
本日の概要 : Webサービスの設計について
書籍の構成
- 第1部 : Web概念
- 第2部 : URI
- 第3部 : HTTP
- 第4部 : ハイパーメディアフォーマット
- 第5部 : Web サービスの設計
※今回は、第5部 Web サービスの設計についてまとめております。
第5部 Web サービスの設計
WebサービスやWeb APIのインターフェイスはHTTPとURIを用いてを設計・実装しますが、実はそれだけでは不十分です。
第5部では、特にリソースをどのように設計するかについて解説されております。
読み取り専用のWebサービスの設計
リソース設計とは何か
書き込み可能なWebサービスの設計
サービスの設計
- リソースの更新
- ※バルクアップデート（PUTでリソース全体を送信する更新方法）
- 利点：クライアントの実装が簡単になる
- 欠点：送受信するデータが大きくなる
- ※パーシャルアップデート（PUTでリソースの一部だけを送信する更新方法）
- 利点：送受信するデータが少なくなる
- 欠点：GETしたリソースの一部を修正してそのままPUTする、という使い方ができなくなる
- リソースの削除
- 削除したいリソースのURIにDELETEを送り、リソースを削除する（※親リソースに従属する子リソースは、親リソースの削除に伴って削除する）
- バッチ処理
- 大量データを処理する際は、パフォーマンスが問題になることがあるため、作成・更新したいリソースを一括で送信できるように設計する
- トランザクション
- 複数のリソースにまたがった変更をひとまとまりに扱う場合に発生しうる問題を防ぐように、処理が成功するか、失敗した場合は元の状態に戻すことを保証する
設計のバランス
各種のパラメータを加味して、自分が最もバランスが取れていると感じる所に落ち着かせるのが設計作業の上で重要
- なるべく全体をシンプルに保つ
- 設計が複雑になったら1段階メタな視点で全体を考え直す
- 困ったらリソースに戻って考える
- HTTPメソッドでは実現できない機能があると感じたら、それが独立した別のリソースで代替できないかを考える
- 本当に必要ならPOSTで何でもできる
- 実現するために必要であればPOSTを用いることが賢明
リソースの設計
関係モデルからの導出
オブジェクト指向モデルから導出
- クラスの持つメソッドを操作結果リソースへと変更することが重要
- 特徴：対象システムの分析モデルをオブジェクト指向言語のクラスとインスタンスに対応付ける
