Using HTTP request methods
Here is a quick guide to pick the right HTTP method and stay aligned with RFC 9110 semantics. Handy when you wonder “Should this be POST or PUT?”
Start with semantics
HTTP methods are signals of intent. Following RFC 9110 keeps caches, proxies, and browsers predictable.
Key terms
- safe: the client requests essentially read-only behavior (GET/HEAD/OPTIONS/TRACE). Incidental effects such as access logging are not prohibited.
- idempotent: multiple identical requests have the same intended server effect as one request (GET/HEAD/PUT/DELETE/OPTIONS/TRACE). Response codes and bodies need not stay identical.
- PATCH is defined by RFC 5789, not incorporated into the method definitions of RFC 9110. It does not guarantee idempotency; this depends on the operation. Use a strong ETag and If-Match where needed.
- Safety and cacheability are different properties. GET/HEAD can be stored; OPTIONS/TRACE cannot use ordinary HTTP caching. POST/PATCH require specific conditions.
Method cheat sheet
Typical use, safety, and body handling at a glance (PATCH: RFC 5789; other listed methods: RFC 9110).
Main methods
| Method | Purpose | Properties |
|---|---|---|
| GET | Retrieve a representation | Safe; idempotent |
| HEAD | Retrieve headers without content | Safe; idempotent |
| POST | Creation or processing | Unsafe; no idempotency guarantee |
| PUT | Create or replace state at the URI | Unsafe; idempotent |
| PATCH | Apply a patch | Unsafe; no idempotency guarantee |
| DELETE | Request deletion | Unsafe; idempotent |
| OPTIONS | Discover communication options | Safe; idempotent |
| TRACE | Reflect request for diagnostics | Safe; idempotent |
Request bodies and caching
Storage also depends on status and headers. POST/PATCH need explicit freshness and Content-Location matching the target URI, for reuse by later GET/HEAD requests. See caching conditions. The separate CORS preflight cache for OPTIONS is explained below.
| Method | Request body | HTTP cache |
|---|---|---|
| GET | Usually omitted | Allowed |
| HEAD | Usually omitted | Allowed |
| POST | Data needed for processing | Conditional |
| PUT | New representation | Not cacheable |
| PATCH | Patch document | Conditional |
| DELETE | Usually omitted | Not cacheable |
| OPTIONS | If present, Content-Type is required | Not cacheable |
| TRACE | Prohibited | Not cacheable |
Design notes
Choosing the method carefully keeps clients, caches, and intermediaries predictable.
Heuristics
- Do not assign requested state changes, such as purchases or deletions, to GET. Previews and prefetchers can call it automatically.
- POST is for “create or trigger.” Assume duplicates; use idempotency keys or replay protection if needed.
- PUT means “make this URL look exactly like the payload.” Send the full state and pair with If-Match to avoid lost updates.
- PATCH is for partial updates. If applying the patch twice would break things, enforce conditional requests (ETag/revision).
- DELETE idempotency concerns its effect. A first 204 and a later 404 are compatible with the resource remaining deleted. Repeating the request must not delete another resource.
- HEAD sends no response content and should normally return the same headers as GET. Fields determined only during content generation may be omitted; exact header equality is not mandatory.
Common pitfalls
Operational snags to watch for.
Checklist
- Do not use GET to request mutations. Crawlers, previews, and prefetchers can trigger such actions.
- GET request bodies have no generally defined semantics and can be rejected. Usually use query parameters; design a processing POST endpoint when sensitive or large search data must go in a body.
- When sending content, provide the matching Content-Type. For JSON, use application/json and UTF-8 for interchange. No charset parameter is defined for application/json. PATCH needs a supported patch format.
- Use an idempotency key only when the API supports it. The server must define retention, duplicate detection, and handling of different payloads under the same key; a header alone is insufficient.
- CORS permission results use a dedicated preflight cache, separate from the HTTP cache. Access-Control-Max-Age sets its lifetime. Omission has a short default lifetime, so preflight need not run on every request.
- TRACE clients must not send sensitive information such as credentials or cookies. Servers should exclude sensitive fields from the reflected response.
Takeaway
Separate method properties from response codes and caching rules. Continue with status codes, caching conditions, and conditional requests for conflicting updates.
Specifications
RFC 9110 §9 / RFC 5789 / RFC 8259 §8.1 / §11 / Fetch: CORS-preflight cache