REST API Methods and Idempotency

HTTP methods, safe vs unsafe semantics, and idempotency examples for API consumers and designers.

View
StandardDetailedCompact
Export
Copy the compact sheet, download it, or print it.
Download
`D` dense toggle · `C` copy all

HTTP method semantics

Map the method to the expected behavior.

GET retrieves data

Read without changing server state.

httpANYhttpgetsafe
http
GET /products/sku_123

GET is safe and should not mutate state. It is commonly cacheable and bookmarkable.

POST creates or triggers processing

Submit a new resource or command-like workflow.

httpANYhttppostcreate
http
POST /orders

POST is not inherently idempotent. Repeating the same request may create duplicates unless you add idempotency controls.

PUT replaces state

Send a full replacement representation.

httpANYhttpputidempotent
http
PUT /profiles/123

PUT is generally idempotent: sending the same representation repeatedly should lead to the same final state.

PATCH partially updates state

Send only the fields that change.

httpANYhttppatchpartial-update
http
PATCH /profiles/123

PATCH may or may not be idempotent depending on the patch format and operation design.

DELETE removes a resource

Delete one item by ID.

httpANYhttpdeleteidempotent
http
DELETE /profiles/123

DELETE is commonly designed to be idempotent: deleting an already-deleted resource should not keep changing state.

HEAD fetches headers only

Check resource metadata without the body.

httpANYhttpheadheaders
http
HEAD /reports/monthly.pdf

HEAD can be useful for existence checks, cache validation, or content-length inspection.

OPTIONS advertises supported interactions

Inspect available methods or CORS capabilities.

httpANYhttpoptionscors
http
OPTIONS /users

OPTIONS is often used by browsers for CORS preflight requests and by tooling to inspect server capabilities.

Idempotency patterns

Protect writes from accidental duplication.

Use an idempotency key for POST

Deduplicate retryable create requests.

httpANYrestpostidempotency-key
http
POST /payments
Idempotency-Key: 8f3dc9d4-7d3e-4c66-9f44-7d85f0f86dd1

This pattern helps clients safely retry network-failed POST requests without creating duplicate side effects.

Client-chosen resource ID via PUT

Make resource creation naturally idempotent.

httpANYrestputupsert
http
PUT /devices/device_123

When the client supplies the stable identifier, repeated PUT requests can converge on the same final state.

Use set-style PATCH operations

Favor deterministic patches.

jsonANYrestpatchjson
json
{
  "display_name": "Jane Smith",
  "timezone": "America/Los_Angeles"
}

Field assignment patches are easier to reason about than increment-style or append-style patches when idempotency matters.

Avoid mutations on GET

Do not track writes in the same endpoint contract.

textANYrestgetanti-pattern
text
Avoid: GET /posts/123/mark-read

A GET endpoint should not change business state. Use a dedicated write route if you need to record events or acknowledgements.

Recommended next

No recommendations yet.