What does idempotent mean for an HTTP method?

An idempotent method produces the same server state whether you send the request once or many times. GET, HEAD, PUT and DELETE are idempotent; POST and PATCH are not, because repeating them can create duplicates or compound changes.

Which HTTP methods are safe?

Safe methods are read-only and must not change server state: GET, HEAD, OPTIONS and TRACE. POST, PUT, PATCH, DELETE and CONNECT are not safe because they are intended to cause effects.

What is the difference between PUT and PATCH?

PUT replaces a resource entirely with the body you send and is idempotent. PATCH applies a partial modification and is not idempotent, because repeated patches (for example "add 1") can keep changing the resource.

When should I use POST versus PUT?

Use POST to create a resource when the server assigns the identifier, or for non-idempotent actions. Use PUT to create or replace a resource at a URL the client already knows, where sending it twice has the same result.

Are GET requests cacheable?

Yes. GET and HEAD responses are cacheable by default, which is why they should never change server state. POST responses are only cacheable with explicit freshness headers, and that is uncommon.

Is this reference loaded from a server?

No. The full table and the search run entirely in your browser — nothing is fetched and nothing you type is uploaded.

What is the HTTP Methods Reference?

A searchable HTTP methods reference covering GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE and CONNECT — with whether each is safe, idempotent, cacheable and takes a body, per RFC 9110. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

HTTP Methods Reference

Name: HTTP Methods Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

HTTP methods reference

A quick, searchable table of the HTTP methods defined by RFC 9110 — GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE and CONNECT — and the properties that matter when designing an API. It is a fast way to settle “is this idempotent?” and “can I cache this?” questions while building REST endpoints.

The three properties that shape API design

Safe

A method is safe if it is read-only by design — it must not modify server state. GET, HEAD, OPTIONS and TRACE are safe. Safe methods can be called freely by browsers, crawlers and prefetch mechanisms without side effects. A GET request should never delete a resource — ever.

Idempotent

A method is idempotent if sending it once or ten times leaves the server in the same state. GET, HEAD, PUT, DELETE, OPTIONS and TRACE are idempotent. Idempotency is what makes retries safe: if a network error causes a PUT to time out, you can safely retry it. POST and PATCH are not idempotent — POST-ing twice may create two resources; PATCH-ing twice may compound a change (for example “add 1” applied twice adds 2).

Cacheable

Only GET and HEAD are cacheable by default per RFC 9110. POST responses may be cached if the server includes explicit freshness headers, but this is uncommon. All other methods are not cacheable. Caches bypass non-cacheable methods entirely, which is why GET should be used for any read that benefits from caching.

Full method table

Method	Safe	Idempotent	Cacheable	Request body	Typical use
`GET`	Yes	Yes	Yes	No	Retrieve a resource
`HEAD`	Yes	Yes	Yes	No	Headers only — check existence or freshness
`POST`	No	No	Rarely	Yes	Create a resource; submit data
`PUT`	No	Yes	No	Yes	Replace a resource at a known URL
`PATCH`	No	No	No	Yes	Partially update a resource
`DELETE`	No	Yes	No	Optional	Remove a resource
`OPTIONS`	Yes	Yes	No	No	Discover allowed methods; CORS preflight
`TRACE`	Yes	Yes	No	No	Loop-back diagnostic (rarely used; often disabled)
`CONNECT`	No	No	No	N/A	Tunnel (used by HTTPS proxies)

When to use PUT vs PATCH vs POST

This is the most common source of REST API design confusion:

POST /articles — the server assigns the new article’s URL. Not idempotent: two calls may create two articles.
PUT /articles/42 — replace article 42 entirely with the body you send. Idempotent: the same body sent twice produces the same result.
PATCH /articles/42 — apply a partial change. Not idempotent if the patch is relative (e.g. “increment views by 1”). Idempotent only if the patch is absolute (e.g. “set title to X”).

CONNECT and OPTIONS in practice

OPTIONS is the method browsers send automatically as a CORS preflight request — they send OPTIONS before a cross-origin POST/PUT/DELETE to ask the server which origins and methods it permits. Your API needs to handle OPTIONS for CORS to work.

CONNECT is used by HTTP proxies to establish a tunnel for HTTPS: the client sends CONNECT example.com:443 to the proxy, and the proxy opens a raw TCP tunnel. You rarely write CONNECT handlers yourself; it is handled by proxy software.

Everything runs in your browser; nothing is uploaded.