HTTP Methods Reference

HTTP methods define the operation a client performs on a resource. This table covers 9 standard methods with safe/idempotent flags, request body and typical use.

How It Works

HTTP methods (verbs) express the action semantics on a resource. GET reads, POST creates, PUT replaces wholly, PATCH edits partially, DELETE removes. Safe methods (GET/HEAD/OPTIONS) only read and do not change server state.

Idempotence means repeated identical requests equal one: GET/PUT/DELETE are idempotent, POST is not (retrying may create duplicates). RESTful design and infrastructure (caches, retries) rely on these guarantees.

When to Use This Table

This table is for choosing an HTTP method or deciding whether an endpoint should be POST or PUT. It gives safety, idempotency, whether a body is allowed and the typical semantics for each. Most REST debates (can POST substitute for PUT, can DELETE be called twice) find their criterion here.

When not to consult it: you are designing the business semantics or versioning strategy of an API. A correct method does not make a correct interface — resource modelling, nesting, pagination and filtering, and error taxonomies are separate concerns that a method table cannot answer.

Rule of thumb: first ask whether the operation changes server state, then whether repeating the identical request yields the same result as running it once. Only two negatives make a GET; state-changing and idempotent means PUT or PATCH; state-changing and non-idempotent means POST.

Mind that POST is not a synonym for non-idempotent: a repeated POST /login returns the same outcome, while a repeated POST /orders creates several orders. Idempotency is decided by the interface design, not by the method name; the table gives common conventions rather than rules.

Boundaries and Common Pitfalls

Using PATCH as PUT muddles partial-update semantics
PUT requires a full replacement: fields absent from the body get cleared or reset to defaults. PATCH submits only the changed fields. So an endpoint that merely renames a user will reset the email and avatar if it uses PUT. The subtler trap is that PUT is only idempotent when the implementation truly replaces; many frameworks merge on PUT, at which point PUT is no longer idempotent and client retries corrupt data.
Safe methods do not mean side-effect free
A GET /delete-all?id=1 violates the spec yet is perfectly valid syntax, and neither clients nor browsers will stop it. Safe is only a semantic convention: if the server writes on GET, caching, prefetch, crawlers and retries amplify the damage. Real protection is server side — accept writes only on POST/PUT/PATCH/DELETE, forbid database writes inside GET handlers, and put it in the review checklist.
DELETE idempotency depends on the implementation; repeats must be safe
The spec requires DELETE to be idempotent, so deleting twice equals deleting once. Many implementations return 404 the second time, which clients and gateways treat as failure and answer with a retry storm. The robust approach is to return 200/204 (or 200 with an alreadyDeleted marker) on repeats, backed by soft deletes or version numbers so that deleting the same resource really is re-entrant.
Method drives caching, and mistakes make changes appear not to take effect
GET and HEAD are cacheable by default; POST, PUT, PATCH and DELETE are not. So a stale read after an update usually means the read was a cached GET while the write went out as POST. Inspect Cache-Control and ETag rather than assuming the server received the write. Note also that non-GET responses can still be cached unless declared otherwise, and a CDN-cached GET will not even reach the origin after the backend changes.

How This Relates to Neighbours

For status code semantics (the difference between 201 and 200, who returns 502), use the in-site HTTP status codes page; this table is only about method choice.

Cross-origin, allowed methods and preflight belong to the CORS mechanism, which is a different topic from method semantics.

Designing API versioning and compatibility needs advice this table cannot give — once a method ships it is very hard to change.

If the goal is debugging idempotency of a specific endpoint, the idempotency column is only a common convention; you need the implementation and retry logic.

Practical Snippet

Key points: (1) never write inside a GET handler — the semantic convention does not stop caches or crawlers; (2) idempotency is decided by the implementation, not the method name, since POST can be idempotent and a merge-style PUT is not; (3) create endpoints need an Idempotency-Key header to prevent duplicate submissions; (4) use PATCH for partial updates, since PUT replaces and silently clears fields you omitted; (5) a repeated DELETE should return 200/204 rather than 404, or clients will retry-storm; (6) when a change does not show up, inspect Cache-Control and Age before suspecting the write.

# ① 只读 vs 写操作：GET 绝不产生副作用
curl -sS https://api.example.com/users            # ✅ 安全
curl -sS -X DELETE https://api.example.com/u/1   # ❌ 用 DELETE，别用 GET 带副作用

# ② 幂等重试演示：GET 重复 3 次结果一致
for i in 1 2 3; do curl -sS https://api.example.com/orders/42; echo; done

# ③ POST 创建：重复调用会创建多笔（所以客户端要带 Idempotency-Key）
curl -sS -X POST https://api.example.com/orders   -H 'Content-Type: application/json'   -H 'Idempotency-Key: 7f3a9c1e'   -d '{"sku":"A1","qty":1}'

# ④ PUT 全量替换 vs PATCH 局部更新
curl -sS -X PATCH https://api.example.com/users/7   -H 'Content-Type: application/json'   -d '{"nickname":"new-name"}'      # ✅ 只改昵称
# 若用 PUT 且只传 nickname ⇒ email/avatar 会被重置为默认值

# ⑤ 观察缓存头（排查「改了却读到旧值」）
curl -sSI https://api.example.com/orders/42 | grep -iE 'cache-control|etag|age'
# Age > 0 ⇒ 命中缓存，解释了为什么改动没立即生效

# ⑥ 405 的正确处理：方法不被允许
curl -sS -X DELETE https://api.example.com/health
# ⇒ 405 Method Not Allowed，响应应带 Allow: GET, HEAD

Practical Notes

PATCH is not a lightweight POST; it must support partial updatesA PATCH payload is a change description: fields that are absent must stay untouched. Implementations that treat PATCH as a full overwrite silently drop concurrent changes. Use PUT for replacement, PATCH for patching, and explicitly no-op missing fields.
GET requests with a body get dropped by proxiesThe spec does not forbid a GET body, but intermediaries (some CDNs, default Nginx setups, older fetch implementations) discard it. Put query parameters in the query string instead of stuffing JSON into a GET body.
"Safe" means it does not change server state, not that it has no side effectsGET is a safe method, yet it still writes access logs, metrics and caches, and can be prefetched. Never put "confirm order" or "delete account" behind a GET: browsers prefetch and crawlers may follow it.

Data Sources

RFC 9110 §9 (method definitions, safety and idempotence)

Codes, names and definitions above come from public specifications; we claim no originality over the specification data itself. The arrangement, Chinese annotations and practical notes on this page are written by us.

Method	Safe	Idempotent	Body	Description
GET	Yes	Yes	No	Retrieve a representation; safe, idempotent, cacheable.
HEAD	Yes	Yes	No	Like GET but no body; used to inspect headers only.
POST	No	No	Yes	Submit data to process; usually creates a sub-resource. Not safe/idempotent.
PUT	No	Yes	Yes	Replace the entire resource with the payload. Idempotent.
PATCH	No	No	Yes	Apply partial modifications to a resource. Not idempotent.
DELETE	No	Yes	Optional	Delete the resource. Idempotent.
OPTIONS	Yes	Yes	No	Describe communication options; used in CORS preflight.
CONNECT	No	No	No	Establish a tunnel to the server (e.g. HTTPS via proxy).
TRACE	Yes	Yes	No	Echo the request for diagnostics; often disabled for security.

Frequently Asked Questions

What is the difference between GET and POST?

GET retrieves a resource with params in the URL; it is safe, idempotent and cacheable. POST submits data in the body; it is neither safe nor idempotent and is not cached by default.

What is the difference between PUT and PATCH?

PUT replaces the entire target resource with the full representation (idempotent). PATCH applies partial changes with only the fields to modify (not idempotent).

What does idempotent mean?

Making the same request once or many times results in the same final server state. GET/PUT/DELETE are idempotent; POST/PATCH are not. Idempotence lets clients safely retry after a timeout.

What is the OPTIONS method for?

It returns the HTTP methods a resource supports. Its most common use is the CORS preflight request that browsers send automatically before a cross-origin request.