HTTP Methods Reference

GET, POST, PUT, PATCH, DELETE and more — safety, idempotency, and use cases

Safety & Idempotency Matrix
Method Safe Idempotent Has Body Cacheable Use Case
Method Details

What is HTTP Methods Reference?

HTTP Methods Reference is a concise guide to all nine HTTP request methods defined in RFC 9110 (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH), plus the semantic conventions and safe/idempotent properties that determine how servers, proxies, and caches treat each method.

HTTP methods define the intent of a request. Choosing the right method is not just semantic — it has practical consequences. GET requests can be cached and bookmarked. PUT requests can be safely retried because they are idempotent. DELETE requests should not be retried blindly. POST requests may trigger side effects on every call. Browsers and HTTP clients rely on these properties to decide how to handle responses, retries, and preflight requests.

For REST API designers, method semantics are the foundation of a usable API contract. Using POST for everything (a common antipattern) loses caching, idempotency, and documentation clarity. This reference describes when to use each method, what response codes to expect, and how CORS preflight requests interact with non-simple methods.

How to Use

  1. Find the method you are implementing or debugging in the table.
  2. Check the Safe column — safe methods (GET, HEAD, OPTIONS) do not modify server state and can be cached.
  3. Check the Idempotent column — idempotent methods (GET, PUT, DELETE) produce the same result when called multiple times.
  4. Read the common response codes for each method to set correct expectations in your API.
  5. Review the CORS notes to understand which methods trigger preflight OPTIONS requests.

Examples

GET /users/123

Result: Returns the user resource. Safe, idempotent, cacheable. Response: 200 OK with user JSON

PUT /users/123 with full user body

Result: Replaces the user resource. Idempotent — calling it 5 times has the same result as calling it once. Response: 200 OK or 204 No Content

PATCH /users/123 with {name: 'Alice'}

Result: Partial update — only the name field changes. Not necessarily idempotent. Response: 200 OK with updated resource

Frequently Asked Questions

What is the difference between PUT and PATCH?

PUT replaces the entire resource with the request body. PATCH applies a partial modification. If you send PUT with only a name field, other fields may be cleared. PATCH only updates the fields you specify.

Why is POST not idempotent?

POST is intended to submit data that creates a new resource or triggers a side effect. Calling POST /orders twice may create two orders. For idempotent creation, use PUT with a client-generated ID or add an idempotency key header.

What is an OPTIONS request for?

CORS preflight. Before a cross-origin request with a non-simple method or headers, the browser sends OPTIONS to ask the server what it allows. The server responds with Access-Control-Allow-Methods and Access-Control-Allow-Headers.

When should I use 204 No Content vs 200 OK?

Return 200 OK when the response includes a body (the updated resource, a confirmation object). Return 204 No Content when the operation succeeded but there is nothing meaningful to return — common for DELETE and some PUT endpoints.

What is the difference between safe and idempotent?

Safe means the method does not modify server state (GET, HEAD, OPTIONS, TRACE). Idempotent means repeating the call produces the same state (GET, PUT, DELETE, HEAD, OPTIONS, TRACE). All safe methods are also idempotent, but not vice versa — DELETE is idempotent but not safe.

Related Tools