Quick Comparison
| Method | Safe | Idempotent | Body | Cacheable | Use |
|---|
Interactive guide to HTTP methods — idempotency, safety, use cases, and request/response examples.
| Method | Safe | Idempotent | Body | Cacheable | Use |
|---|
HTTP Method Reference documents the semantics, use cases, idempotency, and safe/unsafe properties of all HTTP methods: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT, TRACE, and WebDAV methods. Each method includes the RFC definition, browser support, REST API usage conventions, and examples of correct vs incorrect usage.
HTTP methods (verbs) define the action to perform on the resource identified by the URL. Key properties: Safe: a method is safe if it does not change server state -- only GET, HEAD, OPTIONS, TRACE are safe. Idempotent: calling the method multiple times produces the same result as calling it once -- GET, HEAD, PUT, DELETE, OPTIONS, TRACE are idempotent. POST is neither safe nor idempotent. PATCH may or may not be idempotent depending on the operation.
REST API conventions: GET /users (list all), GET /users/1 (get one), POST /users (create new), PUT /users/1 (full replace), PATCH /users/1 (partial update), DELETE /users/1 (delete). HTTP/1.1 (RFC 7231) defines most methods; PATCH was added in RFC 5789 (2010).
REST resource operations
Result: GET /items -> list / POST /items -> create / PUT /items/1 -> replace / PATCH /items/1 -> update / DELETE /items/1 -> remove
Idempotent vs non-idempotent
Result: PUT /user {name:'Alice'} x3 -> same result each time. POST /users {name:'Alice'} x3 -> creates 3 users
OPTIONS for CORS preflight
Result: OPTIONS /api/data -> Response: Allow: GET, POST, PUT / Access-Control-Allow-Methods: GET, POST
What is the difference between PUT and PATCH?
PUT replaces the entire resource with the request body -- if you omit a field, it is deleted or set to null. PUT is idempotent: sending the same PUT three times = same result. PATCH applies a partial update -- only the fields in the request body are modified; other fields remain unchanged. PATCH may or may not be idempotent depending on the operation (e.g., PATCH {increment: 1} is not idempotent). Use PUT when the client sends the complete resource, PATCH for partial updates.
What is the difference between POST and PUT for creating resources?
POST to a collection URL creates a new resource with a server-generated ID: POST /users creates a user, server generates ID, returns 201 Created with Location header. POST is not idempotent -- sending twice creates two resources. PUT to a specific URL creates or replaces a resource with a client-specified ID: PUT /users/my-id -- idempotent. REST convention prefers POST for resource creation with server-assigned IDs (most common).
What is the OPTIONS method used for?
OPTIONS returns the allowed HTTP methods for a URL: Allow: GET, POST, DELETE. Primary use: CORS preflight requests. Before cross-origin requests with non-simple methods (PUT, PATCH, DELETE) or custom headers, browsers send an OPTIONS preflight to check if the server allows the cross-origin request. The server responds with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. Servers must handle OPTIONS requests to support cross-origin API calls.
What does idempotent mean in HTTP?
An HTTP method is idempotent if making the same request multiple times produces the same result as making it once. Idempotent methods: GET, HEAD, OPTIONS, PUT (replaces resource -- same body = same result), DELETE (deleting twice is fine -- second request returns 404 but no additional state change). Non-idempotent: POST (creating twice = two resources). Idempotency is important for reliability: it is safe to retry idempotent requests without risk of unintended side effects like double charges or duplicate records.
What is the HEAD method and when should I use it?
HEAD is identical to GET but the server returns only headers, not the response body. Use HEAD to: check if a resource exists without downloading it (check status code). Get metadata: Content-Length (file size before downloading), Content-Type, Last-Modified, ETag. Validate cached content without re-downloading. Test if a URL is accessible. All successful responses to HEAD must have the same headers as the equivalent GET response.