WebAPIのPATCHについて

WebAPIのPATCHの挙動について改めて調べたことをgunmawebというコミュニティでLTしました。

Transcript

1. WebAPIのPATCHについて Takashi Hori
2. 自己紹介 Twitter: @t_pori418 From: 神奈川(now) <- 館林生まれ Work: 　(近況) 都内のWeb系でチームのTechleadをしています。 副業で0->1のWebエンジニアもやってます。 Language: Ruby, PHP, C#, Python, TypeScript
3. 問: REST API、作ってますか？
4. ふわっとした知識で話すとよく発生する議論 • 更新処理ってPUTでいいんだっけ？PATCH？どっち？ • 更新処理を実装する時、「フィールドがない」「null」「空」の扱いってどうなるんだっ け？
5. PUTとPATCHについて 一般的には... • PUT ◦ 渡されて来たパラメータでデータを置き換える（ nullやundefinedも） ◦ つまりモデルをdelete -> insertする • PATCH ◦ 渡されてきたパラメータのみデータを置き換える ◦ つまり部分更新が可能
6. でも結構適当にやってるパターン、よく見ませんか？ • 更新処理は一律PUT！そもそもRESTfulな設計は業務アプリでは無理だし！ • 返却するステータスコードは全部200で！ とか 正直、HTTPのメソッドやステータスコードはなんでも動くんですが、 API実装する側も利用する側も挙動が決まってないと困りませんか？ 困りそうだったので一般的にはどうなのか調べました 基本はさっきのスライドの通り、PUTはdelete -> insertなのでPATCHについて。
7. 定番のChatGPT(無料版)に聞くやつ
8. RFC7396 For example, given the following original JSON document: Changing the value of "a" and removing "f" can be achieved by sending: { "a": "b", "c": { "d": "e", "f": "g" } } RFC7396 - JSON Merge Patch 日本語訳 https://tex2e.github.io/rfc-translater/html/rfc7396.html PATCH /target HTTP/1.1 Host: example.org Content-Type: application/merge-patch+json { "a":"z", "c": { "f": null } } ターゲットリソースに適用されると、「 a」メンバーの値は「z」に 置き換えられ、「f」は削除され、残りのコンテンツはそのままに なります。
9. 考えたこと • nullはDB設計次第だが、許容しないようにバリデーションで弾くケースが多そう。だ けど基本的にRFCに則った実装にしておくのが無難そう • RESTfulなAPIではなく、子のモデルも一緒に更新処理かけたい時どうするか問題 ◦ 例えばorders.order_detailsみたいなのがあった時、 order変更APIで、order_deitalsの配列を ごそっと一緒に替えたい。置き換えるのか？とか。そこだけ PUTみたいな挙動になっちゃう { "amount": 1100, "tax": 100, "order_details": [ {id: 1, product_id: 1, amount: 400, tax: 40, tax_rate: 10}, {id: 2, product_id: 2, amount: 600, tax: 60, tax_rate: 10} ] }
10. 配列による更新について、個人的には... • 配列内のオブジェクトそれぞれidをリクエストパラメータに含められるなら ◦ あったら更新、なかったら削除、新しいものは作成という挙動がよさそう • 配列内のオブジェクトそれぞれidをリクエストパラメータに持てない場合 ◦ 紐づくデータを削除→渡されたものをinsertという挙動がよさそう そもそも中身のリソースは PATCH /order_details/{id} で更新をかけていくのが、あるべ き姿なのでは？みたいな意見ありそう こういう事例あるよ、とかあったらぜひ教えてください
11. 以上です！ 良い更新処理実装ライフを！