HTTP Methods Reference

Three properties that matter

Safe — the method does not modify state. Clients (and search engine bots) can call it without side effects.
Idempotent — calling the method N times has the same effect as calling it once. The client can safely retry on failure.
Cacheable — the response can be stored and reused under cache-control rules.

Method	Safe	Idempotent	Cacheable	Body
`GET`	Yes	Yes	Yes	No
`HEAD`	Yes	Yes	Yes	No
`OPTIONS`	Yes	Yes	No	Optional
`TRACE`	Yes	Yes	No	No
`PUT`	No	Yes	No	Yes
`DELETE`	No	Yes	No	Optional
`POST`	No	No	Only with explicit headers	Yes
`PATCH`	No	Generally No	No	Yes
`CONNECT`	No	No	No	No

Method-by-method

GET

Retrieve a representation of a resource. GET requests must not have side effects. Use query parameters, not bodies, to pass arguments.

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

HEAD

Identical to GET but the server returns only headers, no body. Use it to check resource metadata (size, last modified, ETag) without transferring the payload.

POST

Create a new subordinate resource or trigger an action. The semantics of POST are deliberately open — it covers everything from form submissions to RPC-style calls.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "Defient"}

PUT

Replace the resource at the given URI with the request body. PUT is idempotent: submitting the same body twice has the same effect as once. Use PUT for full-document updates and for creating resources at a client-chosen URI.

PATCH

Apply a partial modification. Two common formats are JSON Merge Patch (RFC 7396) and JSON Patch (RFC 6902). PATCH is not guaranteed idempotent — the spec leaves it to the implementation.

DELETE

Remove the resource at the URI. The body is optional and ignored by most servers.

OPTIONS

Discover which methods a resource supports, or perform a CORS preflight. Returns an Allow header with the supported methods.

CONNECT

Tunnel a connection through an HTTP proxy. Used to set up TLS through corporate proxies.

TRACE

Echo the received request back so the client can see what intermediaries did to it. Disabled on most production servers because it can be abused for Cross-Site Tracing attacks.

Idempotency keys. For non-idempotent operations like POST where retries are unavoidable, send an idempotency key in a header. The server caches the first response under that key and replays it on retry. Stripe and others document this pattern in detail.

Choosing the right method

Reading a resource? → GET
Creating a resource at a server-chosen URI? → POST
Creating or replacing a resource at a client-chosen URI? → PUT
Partially updating a resource? → PATCH
Deleting a resource? → DELETE
Discovering what methods are allowed? → OPTIONS