Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
WebAPIのPATCHについて
Search
thori
June 03, 2023
Technology
0
160
WebAPIのPATCHについて
WebAPIのPATCHの挙動について改めて調べたことをgunmawebというコミュニティでLTしました。
thori
June 03, 2023
Tweet
Share
More Decks by thori
See All by thori
AIの言う通りにやったら Webアプリが作れるのか試してみた (ChatGPT)
t_pori418
0
960
AWSにおけるアカウント/ユーザーとは何かをなんとなく理解する
t_pori418
0
320
Markdownで登壇資料を作りたい
t_pori418
0
370
GitHub Projectsのみでプロダクト開発を管理する
t_pori418
0
300
Nuxt.jsから始めるPWA生活
t_pori418
0
950
10分でAmazon API GatewayにOpen API 3.0のAPI仕様をインポートする
t_pori418
1
960
AWSサーバーレスアーキテクチャでWebサイトを構築してみた
t_pori418
0
660
Vue.jsによるSPAのDDDについて考える(導入編)
t_pori418
0
3.3k
Other Decks in Technology
See All in Technology
テスト・設計研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem
gidajun
0
480
ソフトウェアエンジニアリングの知見を活かして データ基盤をいい感じにする on Snowflake [MIERUNE BBQ #10]
mtpooh
2
150
年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~
lycorptech_jp
PRO
3
2.9k
「我々はどこに向かっているのか」を問い続けるための仕組みづくり / Establishing a System for Continuous Inquiry about where we are
daitasu
0
170
頼られるのが大好きな 皆さんへ - 支援相手との期待の合わせ方、突き放し方 -/For_people_who_like_to_be_relied_on
naitosatoshi
1
290
Azure Pipelinesを使用したCICDベースラインアーキテクチャ実践
yuriemori
0
190
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
270
地理情報とAPIのトレンド
nagix
0
160
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
380
[I/O Extended Android 2024] What`s new in Android 2024
kyeongwan
0
220
Featured
See All Featured
Visualization
eitanlees
139
14k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
105
6.8k
Writing Fast Ruby
sferik
623
60k
GraphQLの誤解/rethinking-graphql
sonatard
59
9.6k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
121
18k
How to name files
jennybc
67
96k
Navigating Team Friction
lara
181
13k
Adopting Sorbet at Scale
ufuk
71
8.8k
Fashionably flexible responsive web design (full day workshop)
malarkey
399
65k
The Power of CSS Pseudo Elements
geoffreycrofte
64
5.2k
Large-scale JavaScript Application Architecture
addyosmani
506
110k
Transcript
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} で更新をかけていくのが、あるべ き姿なのでは?みたいな意見ありそう こういう事例あるよ、とかあったらぜひ教えてください
以上です! 良い更新処理実装ライフを!