HTTP Methods Reference

Every HTTP method, what it does, when to use it, and the gotchas.

By Λ · Updated May 18, 2026

HTTP defines nine standard methods. Picking the right one matters more than it looks: the wrong choice breaks caching, idempotency, and CSRF protection in subtle ways. This is the reference I wish I had when learning REST API design.

Quick reference

Method	Safe	Idempotent	Req Body	Res Body	Typical Use
GET	Yes	Yes	No	Yes	Read a resource
HEAD	Yes	Yes	No	No	Read headers only
OPTIONS	Yes	Yes	No	Yes	CORS preflight, discover methods
POST	No	No	Yes	Yes	Create resource or trigger action
PUT	No	Yes	Yes	Yes	Replace resource (full update)
PATCH	No	No	Yes	Yes	Partial update
DELETE	No	Yes	Opt	Opt	Remove a resource
TRACE	Yes	Yes	No	Yes	Loopback diagnostic (rare)
CONNECT	No	No	No	No	Proxy tunnel (HTTPS via proxy)

GET

Read a resource. Should never modify server state. Cacheable.

Use it for

Fetching a single resource: GET /users/42
Listing a collection: GET /users?limit=20
Reading config or static assets

Avoid it for

Anything that changes server state. Even "increment view count" should be POST or PATCH.
Sending sensitive data in query strings (URLs end up in server logs, browser history, referrer headers).

GET /api/users/42 HTTP/1.1
Accept: application/json

POST

Create a resource or trigger an action. Not idempotent.

The lack of idempotency is the practical problem. If a client retries a POST after a network blip, you may get two of whatever was created. Use the Idempotency-Key pattern: client sends a unique header value, server caches the response keyed by it, retries return the cached response.

POST /api/users HTTP/1.1
Idempotency-Key: 8d3e2c2a-...
Content-Type: application/json

{"name": "Alice"}

PUT vs PATCH

The most-misunderstood pair. PUT replaces the entire resource; PATCH applies a partial update.

PUT

The request body is the new state. Fields you omit are removed. Idempotent.

PUT /api/users/42 HTTP/1.1
{"name": "Alice", "email": "alice@new.com"}
# User 42 now has ONLY name and email; anything else is wiped.

PATCH (Merge Patch, RFC 7396)

Body is a JSON object; provided fields are updated, omitted fields are unchanged.

PATCH /api/users/42 HTTP/1.1
{"email": "alice@new.com"}
# Only email updates; name and everything else preserved.

PATCH (JSON Patch, RFC 6902)

Body is an array of operations. More expressive but less common.

PATCH /api/users/42 HTTP/1.1
[{"op":"replace","path":"/email","value":"alice@new.com"}]

DELETE

Remove a resource. Idempotent: calling it twice returns the same result (resource gone). Second call typically returns 404 or 410.

Response body is optional. Some APIs return 204 No Content; others return the deleted resource as a courtesy. Both are acceptable.

HEAD

Like GET but the server omits the response body. Useful for existence checks, getting Content-Length before downloading, or checking Last-Modified without transferring the file.

OPTIONS

Returns allowed methods. Most importantly, this is the method used in CORS preflight requests: browsers send OPTIONS first for non-simple cross-origin requests to check the server's CORS policy. See the CORS debugging post for the full diagnostic flow.

TRACE and CONNECT

TRACE: echoes the request back. Most servers disable it because of XST (cross-site tracing) attacks.

CONNECT: how HTTPS tunnels through HTTP proxies. The client sends CONNECT host:443, the proxy opens a raw TCP tunnel.

Last updated May 19, 2026