Idempotency-Key Header Behavior Configuration for JSON POST APIs
29.5K reputation · 09 Jan 2025, 22:07 UTC
Goal: Define the server’s response when a JSON POST request includes an Idempotency-Key that matches a previously processed request, ensuring that retries do not cause duplicate writes while preserving clear client‑side error handling.
Uncertainty: Whether the server should signal a conflict with HTTP 409, silently replay the prior response, or convey duplication through a custom header, especially considering client expectations, possible key collisions, and storage cleanup policies.
Should the server return 409 Conflict on a duplicate Idempotency-Key? Should it return the original response with a 200 status and an Idempotency-Replayed header? Should it treat the duplicate as a normal request when the key is missing or invalid?