HTTP Method Reference

Reference for HTTP methods — semantics, safety, and idempotency.

Runs locally · Nothing uploaded

HTTP methods9 methods

HTTP request methods with their safe, idempotent, cacheable, and request-body properties
Method	Safe	Idempotent	Cacheable	Request body	Typical statuses	Description
GET	Yes	Yes	Yes	No	200, 304, 404	Retrieve a representation of a resource. Must not change server state.
HEAD	Yes	Yes	Yes	No	200, 304, 404	Identical to GET but the response carries headers only — useful for checking size, type, or existence.
POST	No	No	Rarely	Yes	201, 200, 400, 409	Submit data for the target resource to process. Repeating it may create duplicates; cacheable only with explicit freshness headers.
PUT	No	Yes	No	Yes	200, 201, 204, 409	Replace the target resource entirely with the enclosed representation. Sending it twice leaves the same result.
DELETE	No	Yes	No	Optional	204, 200, 404	Remove the target resource. Idempotent: deleting twice ends in the same state, even if the second call returns 404.
CONNECT	No	No	No	No	200, 407	Ask a proxy to open a TCP tunnel to the target — how HTTPS traffic passes through a forward proxy.
OPTIONS	Yes	Yes	No	Optional	204, 200	Ask what the server supports for a resource. Browsers send it automatically as the CORS preflight.
TRACE	Yes	Yes	No	No	200, 405	Echo the received request back for diagnostics. Usually disabled — it can leak headers via cross-site tracing.
PATCH	No	No	No	Yes	200, 204, 409, 422	Apply a partial modification. Not idempotent in general, though a specific patch format can be.

Safe

The method is read-only by definition: a safe request must not be expected to change server state, so crawlers and prefetchers may issue it freely.

Idempotent

Sending the identical request N times leaves the server in the same state as sending it once. This is what makes automatic retries safe.

Cacheable

The response may be stored and reused. GET and HEAD are cacheable by default; POST only when the response carries explicit freshness information.

PUT vs PATCH

PUT replaces the whole resource with what you send; PATCH changes only the fields you send. To rename a user, PUT /users/7 must carry the complete user object (anything omitted is gone), while PATCH /users/7 {"name": "Ada"} leaves every other field untouched. PUT is idempotent by definition; PATCH is only as idempotent as your patch format makes it.

POST vs PUT

Use POST when the server picks the new resource's URL: POST /orders twice creates two orders. Use PUT when the client knows the exact URL: PUT /orders/42 twice leaves one order in the same state — which is why retrying a timed-out PUT is safe and retrying a timed-out POST needs an idempotency key.

This reference is bundled with the page. Nothing here makes a network request.

Loading tool…

About HTTP Method Reference

Covers every HTTP method — GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and the rest — with its intended semantics, whether it is safe and idempotent, typical status codes, and REST usage conventions. The PUT vs PATCH and POST vs PUT distinctions are spelled out with examples.

All tools · More in this category

HTTP Method Reference

Safe

Idempotent

Cacheable

PUT vs PATCH

POST vs PUT

About HTTP Method Reference

Related tools

Safe

Idempotent

Cacheable

PUT vs PATCH

POST vs PUT