POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog

はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする

[inose660]

重要な提案だと思う。みんな大好き24時間稼働のシステムは、裏側の内部的なリトライによって支えられている。いまは実装をよく調べないと怖くてPostのリトライが出来ないので、保証する仕組みが出来るのは有り難い。

[tkawa]

冪等が目的なら現状でも条件付きPUTで実装できることが多いので、まずそれを検討したほうが良い。リクエストIDなら標準化しても良いと思う

[masatomo-m]

RESTの概念が実質標準化しているのであるとうれしい機能だな。Keyをクライアント側が生成するというところがセキュリティ的につつかれそうなところではあるが、署名済みのセッションIDなどと併用すればよさそう

[takuya_1st]

この手の仕様決まれば、戻る禁止というゴミ機能を絶滅させられるね。

[hachiking]

課金系の処理では広がっている気がするけど、全てのPOSTリクエストにこれを期待するのはさすがにサーバサイドの開発コストが高すぎるかなって気もする。同じレスポンスを永久に保証するのはコストかなり高い

[closer]

クライアントが勝手につけるだけだと、サーバ側が対応してるか保証がない気がするけども。

[hdampty7]

タイムアウトしたときってホント困るんだよな。処理事態は成功なのか失敗なのか分からんからこっち側の処理が進められないんで、結局、警告メールからの手動対応になるんだよな。

[taruhachi]

昔ソシャゲ作った時に似たような事を実装した。多重リクエストが飛んできて、1日1度のデイリーリワードを受け取り損ねたとか言われちゃうんだよね。

[mojimojikun]

例えばこれが標準仕様(?)に取り込まれたとして、その冪等性を担保する処理はどのレイヤ(?)がやるの？httpd側がやるの？とするとhttpdはそのヘッダのついたPOSTへの返信をキャッシュする感じになるの？

[diveintounlimit]

似たような対策はこれまでに山ほどされているはずで、今殊更に重要かというとそうでもないと思う。ぶっちゃけ冪等言いたいだけのようにも見える。

[zyzy]

保証はないにしても実装の基準が出来るだけで、大分楽だとは思う。

[tsuwatch]

Idempotency-Keyヘッダを標準化しても結局アプリケーション側がどうなのかわからないとそんなに意味なさそう

[vuy]

ちょっとよく分かってないんだけど、どのレイヤーが担保するの？LBのお仕事？

[yosuke_furukawa]

まじでmnotさんのリプレイの話参考になるな

[napsucks]

べ、べきとーせい

[threetea0407]

ブコメ見てると冪等なAPIとは何か理解してない人がちらほらいるっぽい

[qtamaki]

なるほど

[umai_bow]

支払いみたいなクリティカルな箇所で使うんだろうけど、クライアント側はそのヘッダーに対応してるか知る術がないから、冪等性を期待した使い方するなら結局ドキュメント読むしかないじゃんみたいなとこない？

[odakaho]

よくわからんけど、「処理は1回でレスポンスがいつも同じ」を「冪等処理」て言っていいの？

[yujiorama]

業務ロジックで回避してたやつだ

[manFromTomorrow]

これずっと考えてたやつだ。支持。

[megomego]

成る程

[noseld]

良い

[shinobue679fbea]

仕組みというか共通の決め事か

[apipix]

まく…冪等処理

[utonn]

これいいね

[iselegant]

マイクロサービスの採用が増えてくると、分散サービス間での冪等性の考慮が重要になってくるので、重要な提案だと思うな。

[tettekete37564]

？？？セッション管理すれば？それこそクライアント側の生成したIDなんて信用して良いはずないし、破壊的データ変更があったら冪等性を保つために各IDごとのキャッシュを保持するなど処理量・データ量が離散的になる

[shiba-yan]

結局サービス側の実装依存だから微妙な提案という感はある

[nakag0711]

GETは冪等って決まってるんだっけ？

[peketamin]

へー

[rryu]

冪等性という名前は微妙だが、処理中のリクエストと同じリクエストを拒否する仕組みを標準化しておけばフレームワークやライブラリレベルで対応できるようになるということだと思う。

[Keisuke69]

👀 リトライのとき重要

[guntz]

箒等