HTTP Cheatsheet
Methods
Use this HTTP reference while you build software engineering projects, review code, or refresh the syntax you reach for most.
All methods with their properties
Safe means read-only, no intended side effect. Idempotent means N identical requests have the same effect as one. Cacheable means a response may be stored and reused.
| Method | Safe | Idempotent | Cacheable | Request body | Success response |
|---|---|---|---|---|---|
GET | yes | yes | yes | no | 200 with a body |
HEAD | yes | yes | yes | no | 200, headers only |
OPTIONS | yes | yes | no | no | 204 with Allow |
TRACE | yes | yes | no | no | 200 echoing the request |
PUT | no | yes | no | yes | 200, 204, or 201 if created |
DELETE | no | yes | no | optional | 204, or 200 with a body |
POST | no | no | rarely | yes | 201 with Location, or 200 |
PATCH | no | no | no | yes | 200 or 204 |
CONNECT | no | no | no | no | 200, then a tunnel |
Every safe method is idempotent. The reverse is false: PUT and DELETE change
state yet are idempotent, which is exactly why clients may retry them after a
timeout and may not retry POST.
PATCH is not idempotent in general, because a patch like "increment by 1"
depends on the current state. A full replacement patch can be.
GET vs POST
| GET | POST | |
|---|---|---|
| Parameters travel in | the query string | the body |
| Cached by browsers and CDNs | yes | no, in practice |
| Appears in history, logs, referrers | yes | no |
| Bookmarkable, shareable | yes | no |
| Length limit | practical, ~8 KB of URL at most servers | effectively none |
| Safe to retry or prefetch | yes | no |
| Correct for a search | yes | only if the query is too large for a URL |
| Correct for a login or payment | no | yes |
Never put a secret, token, or password in a query string. It lands in access
logs, browser history, and the Referer header of the next request.
PUT vs POST vs PATCH
# POST: create, the server assigns the URL curl -X POST https://api.example.com/orders \ -H 'content-type: application/json' \ -d '{"sku":"HU-100","qty":2}' # → 201 Created, Location: /orders/8814 # PUT: create or replace at a URL the CLIENT chooses, full representation curl -X PUT https://api.example.com/orders/8814 \ -H 'content-type: application/json' \ -d '{"sku":"HU-100","qty":5,"status":"open"}' # → 200 or 204, omitted fields are cleared # PATCH: partial update curl -X PATCH https://api.example.com/orders/8814 \ -H 'content-type: application/merge-patch+json' \ -d '{"qty":5}' # → 200 or 204, untouched fields keep their values
| Question | Answer |
|---|---|
| Who picks the resource URL? | POST server, PUT client |
| Sending the whole resource? | PUT yes, PATCH no |
| Repeat the request twice, two rows created? | POST yes, PUT no |
| Missing field means "delete it"? | PUT yes, PATCH no |
Two standard patch formats: JSON Merge Patch
(application/merge-patch+json, RFC 7396) where null deletes a key, and
JSON Patch (application/json-patch+json, RFC 6902) which is an array of
add, remove, replace, move, copy, test operations.
[
{ "op": "replace", "path": "/qty", "value": 5 },
{ "op": "remove", "path": "/coupon" },
{ "op": "test", "path": "/status", "value": "draft" }
]HEAD, OPTIONS, and TRACE
curl -sI https://example.com/big.zip # size and type without the download curl -sX OPTIONS -i https://api.example.com/orders curl -s -o /dev/null -w '%{size_download}\n' -I https://example.com
- HEAD must return exactly the headers GET would, including
Content-Length, with no body. Use it for existence checks, size probes, and
cache validation. A server that computes different headers for HEAD is buggy.
- OPTIONS reports capabilities. The response carries Allow: GET, POST,
OPTIONS for a resource, and in CORS it is the preflight request carrying
Access-Control-Allow-*.
- TRACE echoes the received request, which historically enabled
Cross-Site Tracing to read HttpOnly cookies. Disable it in production.
- CONNECT asks a proxy to open a raw TCP tunnel, which is how HTTPS traverses
a forward proxy.
Method restrictions clients actually hit
| Constraint | Detail |
|---|---|
| HTML forms | only GET and POST, so frameworks tunnel others via _method |
fetch and XHR | all methods, but non-simple ones trigger a CORS preflight |
| Redirect handling | 301, 302, 303 historically rewrite POST to GET, 307 and 308 preserve method and body |
| Caches | may serve GET and HEAD from store, must invalidate on unsafe methods |
| Proxies and WAFs | often block TRACE, CONNECT, and unknown methods outright |
GET with a body | legal to send, but widely ignored or rejected, do not rely on it |
Choosing status codes per method
| Situation | Correct response |
|---|---|
GET on a missing resource | 404 Not Found |
POST created a resource | 201 Created plus Location |
POST accepted for async work | 202 Accepted |
PUT replaced an existing resource | 204 No Content or 200 with the body |
PUT created the resource | 201 Created |
DELETE succeeded | 204 No Content |
DELETE on something already gone | 404, or 204 if you treat it as idempotent |
| Method not supported on this resource | 405 Method Not Allowed plus Allow |
| Method not implemented by the server at all | 501 Not Implemented |
| Body syntax fine, semantics invalid | 422 Unprocessable Content |
405 must include an Allow header listing the methods the resource does
support. Omitting it is one of the most common API bugs.