Closed6

idempotency-key

衝突した場合のHTTPレスポンス

  • リトライ可能なステータスコード
  • 衝突時ステータスコード
  • ボディ

IDの扱い

  • ルール
  • 設定先
  • 保持期間
  • 最大長

RFC Draftでも一部掲載されている

https://tools.ietf.org/id/draft-idempotency-header-01.html#name-implementation-status
API/Spec 推奨リトライコード 重複時コード Body IDルール 設定先
Amazon Pay 429、500、503 記載なし reasonCodeにDuplicateIdempotencyKey V4UUID Header(x-amz-pay-idempotency-key)
LINE Messaging API 500、タイムアウト 409 Error Message 16進表記のUUID Header(X-Line-Retry-Key)
Stripe 省略 記載なし 保存結果 V4 UUIDs Header(Idempotency-Key)
Shopify 省略 記載なし 省略 UUID Body(idempotencyKey/unique_token)
Paypal 省略 記載なし 省略 UUID Header(PayPal-Request-Id)

基本的には、HTTP HeaderにUUID形式の値を指定し、対象リトライコードの場合リトライする。成功可否は200系(リトライコードでない)で判断する。

https://tools.ietf.org/id/draft-idempotency-header-01.html

2

文法

UUIDの場合

Idempotency-Key: "8e03978e-40d5-43e8-bc93-6894a57f9324"

一意性

UUIDまたは同様ののランダム文字列を推奨。

有効性・有効期限

有効期限を定めて良い。その場合はポリシーを公開しクライアントに伝える。

5

サーバでキャッシュされるidempotency-keyの検索において、セキュリティ侵害・攻撃を受ける可能性がある。idempotency-key仕様についての検証が必要。

実装

  • クライアント
    • 仕様に即したキーを付与してリクエスト
  • サーバ
    • ヘッダを見る。存在しなければ400を返す。ドキュメントのURLはボディかヘッダーで示す。
    • キーの形式を検証する。不正な形式であれば400を返す。
    • ストレージを参照する。存在していれば422を返す。処理中である場合409を返す
    • リソースを保存する。20x系を返す。
    • その他エラー系は定めたコードと本文を返す。

迷うポイントは?

  • キーの保持場所(ストレージ選定)
  • 保持期間有無
  • 重複時・処理中のHTTPレスポンスボディ
    • 本文の言及なし。
  • 処理中の判定
    • キーに対して処理中の状態を表現する必要がある。内部で使うAPIで、ステータスコードでリトライ可否を決めているならば、基本的には競合する(処理中)である確率は低いか。
このスクラップは2021/10/05にクローズされました
ログインするとコメントできます