HTTP methods
GET, POST, PUT, PATCH and DELETE — what each promises about safety, idempotency, and when to use it.
The main methods
| Method | Purpose | Has body? | Idempotent? |
|---|---|---|---|
GET | Read a resource | No | Yes |
POST | Create / trigger an action | Yes | No |
PUT | Replace a resource wholesale | Yes | Yes |
PATCH | Partial update | Yes | No (usually) |
DELETE | Remove a resource | Optional | Yes |
HEAD | GET without a body (headers only) | No | Yes |
OPTIONS | Ask what is allowed (used by CORS preflight) | No | Yes |
Idempotent means repeating it has the same effect as doing it once — sending the same DELETE twice should leave things identical. That is what makes retries safe.
PUT vs PATCH vs POST
PUT /users/42
{ "name": "Ada", "email": "ada@example.com", "role": "admin" }
// replaces the whole record - omitted fields may be cleared
PATCH /users/42
{ "role": "admin" }
// modifies only the fields provided
POST /users
{ "name": "Ada" }
// creates something new; server assigns the id💡
PUT must be treated as a full replacement. If you only send one field to a PUT endpoint that expects the whole entity, a correct server will blank the rest — that is the contract, not a bug.
Practical rules
- GET and HEAD must never change server state — they get cached, prefetched, and retried.
- Never put sensitive data in a URL: it lands in logs, Referer headers, and browser history.
- For failures during creation, idempotency keys let clients retry safely without duplicates.
- Return
Locationwith 201 Created pointing at the new resource.
FAQ
Why is my DELETE not idempotent?
If the second call returns 404 it still is — the server state is identical. Idempotency concerns state, not necessarily identical responses.
Can GET have a body?
The spec permits it, but proxies and libraries routinely strip it. Use POST for complex queries.
Related
HTTP status codes HTTP headers
Last refreshed 2026-09-17.