← Lessons

quiz vs the machine

Gold1350

System Design

HTTP Verbs and Idempotency

Picking the right method and knowing which ones are safe to retry blindly.

5 min read · core · beat Gold to climb

What each verb promises

HTTP methods are not interchangeable labels. Each carries a contract that clients, caches, and proxies rely on.

  • GET reads and changes nothing. It is safe.
  • POST creates or triggers work and is not idempotent.
  • PUT replaces a resource fully and is idempotent.
  • DELETE removes a resource and is also idempotent.
  • PATCH applies a partial update and may or may not be idempotent.

Idempotency in plain terms

An operation is idempotent when doing it many times has the same effect as doing it once. Sending the same PUT twice leaves the resource in the same final state. Sending the same POST twice usually creates two records.

This matters because networks fail. A client that never sees a response cannot tell success from a lost reply, so it retries.

For non idempotent creates, hand the client an idempotency key so a retried POST is deduplicated server side.

Key idea

Match the verb to its safety and idempotency contract so retries after failures do not corrupt state.

Check yourself

Answer to earn rating on the learn ladder.

1. Which method is idempotent because repeating it yields the same final state?

2. Why does idempotency matter for unreliable networks?

3. How can a non idempotent POST be made safe to retry?