Concept and mechanism
Method choice has meaning but does not remove the need to understand the API contract. Idempotency describes the intended effect of repeated identical requests; it does not require identical responses or absence of additional logging. A PUT can create then replace the same resource while returning different statuses. This differs from method safety: an idempotent operation can change state. A POST receiving no response may have applied before communication failed. If the contract does not guarantee safe repetition, begin by reconciling the original outcome. Changing the business reference or retrying at several layers does not automatically resolve uncertainty and can increase duplication.
Guided application
A status describes the observed operation. 202 allows acceptance of work not yet completed; the dashboard should track its later outcome. Redirection also has semantics: 307 preserves the method when followed, whereas 303 directs retrieval of another representation. Validate client behavior and the approved destination. For concurrent updates, If-Match can prevent an old version overwriting the current one. On 412, retrieve current state and reconcile differences before retrying with the appropriate precondition. In an exercise, two teams modify the same configuration; removing If-Match makes the visible error disappear while also removing protection against lost updates.
A timed-out POST has an uncertain outcome; 202 is pending acceptance; 412 calls for version reconciliation.
Common pitfalls
Timeout as rollback; 2xx as universal completion; unlimited retries; removing preconditions to eliminate errors.
Related topics: The request and intended representation · Caching, variants, and validation · Versions and message framing
Decide retries from the contract and state rather than timeout alone.
Reference: HTTP Semantics · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance