HTTP Methods Cheatsheet - REST/HTTP Verbs & Idempotency

The hard part of HTTP methods is not recalling the definitions but choosing the right verb for a concrete operation and reasoning about retries and concurrency. This sheet groups verbs by semantics and puts idempotency, safety, body conventions and paired status codes side by side, concentrating on the combinations that actually bite. PUT is a full replacement, so an omitted field becomes a deletion, while PATCH changes only what you send. POST is not idempotent, so a retry creates a duplicate order unless an idempotency key is present. GET and HEAD are safe methods; mutating state inside them breaks the semantics and gets amplified by prefetchers and proxies. Two practical tests decide usage: before shipping, ask whether a client retry would produce a second record, and if so require idempotent design; then ask whether the change can be expressed as a delta, and use full replacement when it cannot. The split with the status-code sheet is deliberate: that one decides what you return, this one decides why you picked the verb.

Reference·27 commands·Last updated 2026-08-02

Core Methods 7

GET

Retrieve a resource; safe and idempotent, so it must have no side effects

POST

Create a sub-resource or submit processing; not idempotent

PUT

Fully replace a resource; idempotent (repeating it gives the same result)

PATCH

Partially update a resource; usually not idempotent unless the semantics guarantee it

DELETE

Delete a resource; idempotent (repeating it converges to the same state)

HEAD

Like GET but returns headers only, for health checks and cache validation

OPTIONS

Ask which communication options the target supports; used by CORS preflight

Idempotency & Safety 4

Safe methods

GET, HEAD and OPTIONS (they do not change server state)

Idempotent methods

GET, PUT, DELETE, HEAD, OPTIONS

Non-idempotent

POST and PATCH (repeated requests are not guaranteed to match)

Idempotency-Key

Request header key sent when retrying POST so the server does not create duplicates

Status Pairing 6

GET → 200 / 304

Success, or the response was served from cache

POST → 201 / 202

Created, or accepted for asynchronous processing

PUT → 200 / 204

Replaced; may return the new resource or no content at all

PATCH → 200 / 204

Partial update succeeded

DELETE → 204 / 200

Deleted; no content, or a short summary of what was removed

Method Not Allowed → 405

Method not allowed: you sent POST to an endpoint that only supports GET

Common Mistakes 4

Change state with GET

Changing state with GET breaks safe semantics; crawlers and prefetchers trigger the side effect by accident

Use PUT as PATCH

Using PUT as if it were PATCH: PUT expects the full resource, so omitted fields get cleared

Duplicate POST submissions

Duplicate POST submission: without an idempotency key a retry creates duplicate resources

DELETE returns 200 with a body

DELETE returning 200 with a body; 204 No Content is the more correct answer

REST Design Conventions 6

GET /users

List resources (a collection)

GET /users/1

Retrieve one resource (a sub-resource)

POST /users

Create a resource

PUT /users/1

Replace user 1 as a whole

PATCH /users/1

Update part of user 1

DELETE /users/1

DeleteUser 1

Tips

PUT sends the full resource — missing fields get cleared; use PATCH for partial updates.
GET/HEAD/OPTIONS are safe methods — never change server state inside them.
Retrying POST needs an Idempotency-Key, or you may create duplicate resources.
The HTTP Status Codes sheet is provided separately; use both when designing APIs.

FAQ

What is the difference between HTTP 302 and 307?

Both are temporary redirects, but 302 lets browsers rewrite POST into GET (many legacy implementations do), while 307 explicitly preserves the original method and body, so POST stays POST. 301 is permanent and typically coerces methods to GET; use 307 when you must keep POST semantics and payload.

Should I use PUT or PATCH?

PUT replaces the whole resource: the client sends the full representation and missing fields are treated as cleared, and it is idempotent so repeats give the same result. PATCH does a partial update with only changed fields but is not guaranteed idempotent. Use PATCH for incremental updates and PUT for full replacement or create.

Can a GET request carry a body?

The spec does not forbid it, but in practice it is unreliable — proxies, caches and CDNs often ignore or drop it, and GET is defined as side-effect-free and cacheable. Send complex queries via URL parameters, or switch to POST when data is large or structurally sensitive. Do not depend on a GET body.

What does idempotency mean and which HTTP methods are idempotent?

Idempotent means repeating the same request any number of times leaves the server state identical, so retries are harmless. GET, PUT, DELETE, HEAD and OPTIONS are idempotent; POST is not, so resending it creates multiple resources. Only auto-retry idempotent requests, and dedupe POST with something like an idempotency key.

Should an API return 404 or 405?

404 means the resource does not exist (wrong path or already gone); 405 means the resource exists but the method is unsupported (e.g. DELETE on a read-only resource) and should include an Allow header listing valid methods. Wrong paths give 404, wrong methods give 405; some APIs return 404 for both as a security boundary, but distinct codes ease integration.

Official References

Each command links to its official documentation below, so you can verify the latest usage and read deeper.

MDN HTTP Methods

Maintained by LaoHand

Publicly updated on Aug 2, 2026, continuously proofread against official docs.

Contact Us

Wrong command or description? Send us corrections, business inquiries or product feedback by email.