HTTP, TLS, and API Semantics

HTTP defines request/response semantics. Methods such as GET, POST, PUT, PATCH, and DELETE communicate intent, while status codes distinguish success, client errors, and server failures. Idempotency matters during retries: repeating an idempotent operation should have the same intended effect as performing it once.

TLS protects data in transit and authenticates the server through certificates. It does not automatically encrypt data at rest or authorize a user to access a resource. Authentication establishes identity; authorization decides whether that identity may perform an action.

Use timeouts and explicit error responses. A client that waits indefinitely can exhaust its own connection pool and upstream capacity. For operations that create payments or orders, use idempotency keys or deduplication so a retry after an ambiguous timeout does not create duplicate effects.

Idempotent API request
POST /v1/payments HTTP/1.1
Host: api.example.com
Authorization: Bearer <access-token>
Idempotency-Key: order-8472-payment-attempt-1
Content-Type: application/json

{"orderId":"order-8472","amount":1299,"currency":"INR"}
💡 The server stores the outcome associated with the idempotency key and returns the same logical result for safe retries. The server must define key scope, retention, payload mismatch behavior, and concurrency handling.
Key Takeaways
  • A timeout does not prove that the server did not perform the operation.
  • TLS, authentication, and authorization solve different problems.
  • Design retries around idempotency and bounded timeouts.