Methods

GET is the workhorse of the Web. It asks the server to return a representation of the resource identified by the request target. Every link you click, every image that loads, every stylesheet and script your browser fetches—​all of them use GET.

The server responds with the resource:

A GET request should not change anything on the server. Loading a page ten times should produce the same result as loading it once, and the server’s state should be identical afterward. This property makes GET requests safe to bookmark, cache, prefetch, and retry on failure. It is the foundation that allows search engines to crawl the Web without accidentally placing orders or deleting files.

GET requests do not carry a body. All the information the server needs is in the URL and the headers.

HEAD is identical to GET, with one difference: the server returns only the status line and headers—​no body. The response headers must be exactly what a GET to the same resource would produce.

This is useful in several situations:

HEAD is required by the HTTP/1.1 specification. Every server that implements GET for a resource must also support HEAD.

POST sends data to the server for processing. Unlike GET, which only retrieves, POST is designed to cause something to happen: submit a form, upload a file, create a new record, trigger a computation.

The data travels in the request body, and the Content-Type header tells the server how it is encoded. Form submissions typically use application/x-www-form-urlencoded; API calls commonly use application/json; file uploads use multipart/form-data.

POST is neither safe nor idempotent. Submitting the same order twice may create two orders. This is why browsers show a warning dialog when you try to refresh a page that was the result of a POST: "Are you sure you want to resubmit the form?" The browser cannot know whether sending the request again is harmless or catastrophic, so it asks.

POST is also the most flexible method. When no other method fits—​when the action does not map neatly to "retrieve," "replace," or "delete"--POST is the general-purpose fallback. Running a search that requires a large query body, triggering a batch job, sending a message—​all of these are reasonable uses of POST.

PUT asks the server to create or replace the resource at the given URL with the contents of the request body. If the resource already exists, PUT replaces it entirely. If it does not exist, PUT creates it.

If the resource is new, the server responds with 201 Created. If it replaced an existing resource, the server responds with 200 OK or 204 No Content.

The critical distinction between PUT and POST is that PUT is idempotent: sending the same PUT request ten times has exactly the same effect as sending it once. The final state of the resource is identical regardless of how many times the request is repeated. POST makes no such guarantee. This difference matters in unreliable networks: if a PUT request times out and the client does not know whether it succeeded, it can safely retry. A POST cannot be retried as safely.

PUT replaces the entire resource. If you PUT a document with three fields to a URL that previously held a document with five fields, the resource now has three fields. The other two are gone. For partial updates, use PATCH.

DELETE asks the server to remove the resource identified by the request target.

A 204 No Content response indicates that the server successfully processed the deletion and has nothing more to say. A 200 OK with a body is also valid if the server wants to return a confirmation message.

Like PUT, DELETE is idempotent. Deleting a resource that has already been deleted should not produce an error in principle—​the end state (the resource is gone) is the same. In practice, many servers return 404 Not Found on repeated deletes, which is technically acceptable since idempotency refers to the server’s state, not the response code.

DELETE requests do not typically carry a body, though the protocol does not forbid one.

PATCH applies a partial modification to a resource. Where PUT replaces the whole thing, PATCH changes only the parts you specify.

PATCH is neither safe nor idempotent in the general case. Whether it is idempotent depends on the patch format: setting a field to a specific value is idempotent; incrementing a counter is not. The protocol leaves this to the application.

PATCH was not part of the original HTTP specification. It was added later in RFC 5789 because the lack of a partial-update method forced developers into awkward workarounds: either sending the entire resource via PUT every time a single field changed, or overloading POST for everything.

OPTIONS asks the server what communication capabilities are available for a given resource, or for the server as a whole.

The Allow header in the response lists the methods the server supports for that resource. An OPTIONS * request (using an asterisk as the request target) asks about the server’s general capabilities rather than a specific resource.

OPTIONS is most visible in the context of CORS (Cross-Origin Resource Sharing). When a web page at app.example.com tries to call an API at api.example.com, the browser first sends an OPTIONS request—​a preflight--to ask the API server whether cross-origin requests are permitted. The API server responds with headers like Access-Control-Allow-Origin and Access-Control-Allow-Methods. Only if the preflight succeeds does the browser send the actual request.

Two additional methods appear in the specification but serve specialized purposes:

TRACE asks the server to echo back the request it received, allowing the client to see what intermediaries (proxies, gateways) may have modified along the way. TRACE is a diagnostic tool. It carries no body, and the response body contains the exact request message the server received. Most servers disable TRACE in production because it can expose sensitive header information.

CONNECT asks an intermediary (usually an HTTP proxy) to establish a TCP tunnel to a destination server. This is how HTTPS traffic passes through HTTP proxies: the client sends CONNECT api.example.com:443, the proxy opens a raw TCP connection to that address, and from that point forward the proxy blindly relays bytes in both directions. The client and destination server then perform a TLS handshake through the tunnel.

Neither method appears in everyday application code, but both are important pieces of HTTP’s infrastructure.

A method is safe if it does not change the state of the server. A safe request is an observation: it looks at something but does not alter it. The safe methods are:

Safety is a promise from the protocol to the user. When you click a link, the browser uses GET because the protocol guarantees that following a link will never, by itself, cause a purchase, a deletion, or any other side effect. This is why search engines can crawl every link they find without fear of triggering dangerous actions.

The promise is semantic, not absolute. A server could delete a database row every time it receives a GET request, but it would be violating the protocol’s contract. Intermediaries, caches, and clients all assume safe methods are safe and make optimization decisions accordingly. A server that breaks this assumption will encounter unpredictable behavior.

A method is idempotent if making the same request multiple times produces the same result as making it once. The server’s state after N identical requests is the same as after one. The idempotent methods are:

All safe methods are automatically idempotent—​reading something twice does not change anything. PUT and DELETE are also idempotent: uploading the same file twice leaves one copy; deleting the same resource twice leaves it deleted.

POST is the notable exception. Submitting the same order form twice creates two orders. Sending the same message twice delivers it twice. This is why idempotency matters: when a network error occurs after a request is sent but before the response arrives, the client does not know whether the request succeeded. For idempotent methods, the safe choice is to retry. For POST, the client must use other mechanisms (confirmation pages, unique transaction tokens) to avoid duplication.

This table is worth memorizing. Caches, proxies, and retry logic throughout the Web’s infrastructure depend on these properties. A cache knows it can store GET responses. A proxy knows it can retry a PUT after a connection failure. A browser knows it must warn before resending a POST. Every one of these decisions flows from the method’s safety and idempotency.

HTTP is extensible. The specification defines the methods above, but servers are free to implement additional methods. The WebDAV protocol, for example, adds LOCK, UNLOCK, MKCOL, COPY, and MOVE for remote file management. Application frameworks sometimes define custom methods for specialized operations.

A server that receives a method it does not recognize should respond with 501 Not Implemented. A server that recognizes a method but does not allow it for a particular resource should respond with 405 Method Not Allowed and include an Allow header listing the methods that are permitted.

Proxies that encounter an unknown method should relay the request downstream if possible, following the principle: be conservative in what you send, be liberal in what you accept.

You now know what each HTTP method means, when to use it, and the safety and idempotency guarantees that make the Web’s infrastructure possible. The next section covers the other half of the conversation: