📣
Resilire Tech News 2025/11/28 - PATCHをやめたい — HTTPメソッド運用の議論
サマリー
今週の社内トピックは「PATCHをやめたい」です。お客様のセキュリティ設定でPATCHが許可されてないケースが多いことやインフラ運用との兼ね合いから、RESTで使っていたPATCH(部分更新)運用を見直す議論が活発になりました。結論としては当面「PATCHをPUTに置き換える」方針をとる方向で合意しつつ、PUT/DELETEを全部やめてPOST一本化する案や、X-HTTP-Method-Overrideを利用する代替案についても技術的に検討を続ける、という流れになっています。
ラジオパーソナリティ風に言うと:「APIのメソッド運用、ちょっとだけお引っ越しします。理由は安全と運用性、フロントの実装体験との折り合いです」。
注目ポイント
-
なぜ見直すのか
- お客様のセキュリティ設定でPATCHが許可されてないケースが多いことやインフラの運用の観点で、PATCHが扱いにくくなってきたため
-
当面の決定事項
- PATCHはPUTに置き換える(部分更新を全フィールド送信のPUTで表現する方向)
- PUT/DELETEを完全に廃止してPOST一本化する案もあるが、インフラチームを含めて追加検討が必要
-
検討中の代替案
- X-HTTP-Method-Overrideヘッダで実質的なHTTPメソッドを表現する(POSTで送ってヘッダでPATCH等を指定する)
- フロント側ではAxiosのカスタムインスタンス等でメソッドとヘッダを書き換えることで開発体験を保てる
社内MTGでの様子
ラフな雰囲気で議論が進みました。主なやりとりを抜粋して構成するとこんな流れでした。
-
問題提起
- 「PATCHを使っている箇所があるが、ユーザー側での許可設定やWAFの都合で扱いにくい」との声が上がった。PATCHの運用が現場でどこまで徹底されているか(PATCH/PUTの使用状況)が指摘された
-
技術的アイデア出し
- シンプルにPATCH→PUTに置き換える(OpenAPI的にもわかりやすい)
- あるいはPATCH的な操作を専用のPOSTエンドポイントで提供する(例: POST /{resource}/{id}/patchのような設計)
- POST一本化する場合、X-HTTP-Method-Overrideで後方互換や表現を保てるのではないかという提案があった
-
フロントエンドの観点
- X-HTTP-Method-Overrideはコード生成や既存クライアントとの相性が懸念だ
- ただしAxiosのカスタムインスタンスが既にあるため、そこに変換ロジックを入れれば開発体験は維持できるという意見が出た。開発時は全てPOSTにして気にせず動かせる利点も指摘された
-
決定と保留点
- 現時点の方針:PATCHをPUTに置き換える(必要に応じて、既存の部分更新は全フィールド更新にして対応する)
- PUT/DELETEを将来的に廃止する場合はX-HTTP-Method-Overrideで対応を検討するが、こちらはWAFやAPIゲートウェイを運用するインフラチームを含めた追加議論が必要だ。セキュリティや監査面の対策も併せて検討する
例(議論で出たパターンの例)
# 既存(部分更新)
PATCH /{resource}/{id}
Content-Type: application/json
{ "notify_by_email": true }
# 当面の置き換え案(全件PUT)
PUT /{resource}/{id}
Content-Type: application/json
{ "notify_by_email": true, "other_field": "..." }
# メソッドオーバーライドの例
POST /{resource}/{id}
X-HTTP-Method-Override: PATCH
Content-Type: application/json
{ "notify_by_email": true }
最後に
今回の議論は「シンプルさ」と「安全性」と「開発体験」のバランスを見直す良い機会になりました。PATCHの運用やインフラ制約で実務的に扱いづらくなる状況が起きても、現実に合わせて実装・運用ルールに落とし込むプロセスが良いですね。
Resilireではこうした現場のエンジニアリング改善を大事にしています。興味を持っていただけた方はぜひカジュアルに話しましょう。採用情報は以下からご覧ください。
また次回も社内で生まれたちょっとした技術的会話をラジオ風にお届けします。ご意見や知見共有、大歓迎です。
Discussion