WebAPIのPATCHについて Takashi Hori 

自己紹介 Twitter: @t_pori418 From: 神奈川(now) <- 館林生まれ Work: 　(近況) 都内のWeb系でチームのTechleadをしています。 副業で0->1のWebエンジニアもやってます。 Language: Ruby, PHP, C#, Python, TypeScript 

問: REST API、作ってますか？ 

ふわっとした知識で話すとよく発生する議論 ● 更新処理ってPUTでいいんだっけ？PATCH？どっち？ ● 更新処理を実装する時、「フィールドがない」「null」「空」の扱いってどうなるんだっ け？ 

PUTとPATCHについて 一般的には... ● PUT ○ 渡されて来たパラメータでデータを置き換える（ nullやundefinedも） ○ つまりモデルをdelete -> insertする ● PATCH ○ 渡されてきたパラメータのみデータを置き換える ○ つまり部分更新が可能 

でも結構適当にやってるパターン、よく見ませんか？ ● 更新処理は一律PUT！そもそもRESTfulな設計は業務アプリでは無理だし！ ● 返却するステータスコードは全部200で！ とか 正直、HTTPのメソッドやステータスコードはなんでも動くんですが、 API実装する側も利用する側も挙動が決まってないと困りませんか？ 困りそうだったので一般的にはどうなのか調べました 基本はさっきのスライドの通り、PUTはdelete -> insertなのでPATCHについて。 

定番のChatGPT(無料版)に聞くやつ 

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」は削除され、残りのコンテンツはそのままに なります。 

考えたこと ● 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} ] } 

配列による更新について、個人的には... ● 配列内のオブジェクトそれぞれidをリクエストパラメータに含められるなら ○ あったら更新、なかったら削除、新しいものは作成という挙動がよさそう ● 配列内のオブジェクトそれぞれidをリクエストパラメータに持てない場合 ○ 紐づくデータを削除→渡されたものをinsertという挙動がよさそう そもそも中身のリソースは PATCH /order_details/{id} で更新をかけていくのが、あるべ き姿なのでは？みたいな意見ありそう こういう事例あるよ、とかあったらぜひ教えてください 

以上です！ 良い更新処理実装ライフを！