What is HTTP Method (GET, POST…)?
Definition
An HTTP method is the verb at the start of an HTTP request that states what the client wants done to the target resource: GET retrieves it, POST submits data for processing, PUT replaces it, PATCH modifies part of it and DELETE removes it. RFC 9110 defines the core methods and whether each is safe, idempotent and cacheable, properties that browsers, proxies, caches and crawlers rely on when handling requests.
Also known as: HTTP verb, request method, HTTP request method, GET and POST
The verb of every request
In HTTP/1.1 every request opens with a line naming the method, the target and the protocol version, for example DELETE /v1/cart/items/77 HTTP/1.1. HTTP/2 and HTTP/3 carry the same information in the :method pseudo-header. Method names are case-sensitive and written in uppercase by convention. The same URL means different things under different methods: GET /v1/cart shows the cart, DELETE /v1/cart empties it. The rest of the message is described under HTTP request and response.
Comparing the methods
RFC 9110 defines eight methods, and RFC 5789 adds PATCH. The ones you meet in day-to-day development compare as follows:
| Method | What it asks for | Safe | Idempotent | Cacheable response |
|---|---|---|---|---|
GET | A current representation of the target | Yes | Yes | Yes |
HEAD | The same headers GET would return, without a body | Yes | Yes | Yes |
POST | Processing of the enclosed data according to the resource's own rules | No | No | Only with explicit freshness information and a matching Content-Location; rare in practice |
PUT | Creation or full replacement of the target with the enclosed representation | No | Yes | No |
PATCH | Application of a set of changes to the target | No | No (not guaranteed) | Only under the same conditions as POST |
DELETE | Removal of the target | No | Yes | No |
OPTIONS | The communication options available for the target | Yes | Yes | No |
The remaining two are niche: CONNECT sets up a tunnel through a proxy, and TRACE echoes the request back for diagnostics and is usually disabled on production servers. If you see a lot of OPTIONS traffic, it is almost certainly browsers sending CORS preflight requests before certain cross-origin calls.
What safe and idempotent really mean
Safe means the client is not asking for any change. The server may still log a GET or bump a counter; the point is that the client cannot be held responsible for such side effects. That is why crawlers, link previewers and browser prefetching follow GET links freely.
Idempotent means repeating an identical request has the same intended effect on the server as sending it once. Responses may differ: a first DELETE can return 204 and a second 404, yet the outcome, a deleted resource, is the same. This property decides whether a client or proxy may automatically retry after a dropped connection, which is explored further under idempotency.
Why GET must never change state
A familiar bug: an admin screen deletes comments through a plain link such as <a href="/comments/delete?id=5">. Anything that assumes GET is harmless, from a chat app generating a link preview to a browser extension, can now delete comments just by fetching the URL. The same design also makes CSRF trivial, since a request can be triggered by an image tag on another site. Anything that writes data should use POST, PUT, PATCH or DELETE. Note that plain HTML forms can only submit GET and POST; the other methods are sent from JavaScript or server-side code.
PUT versus PATCH in practice
// Stored record: {"name": "Sam", "city": "Leeds", "newsletter": true}
PUT /v1/users/31
{"name": "Sam", "city": "York"}
// Result: {"name": "Sam", "city": "York"} → "newsletter" is gone
PATCH /v1/users/31
Content-Type: application/merge-patch+json
{"city": "York"}
// Result: {"name": "Sam", "city": "York", "newsletter": true}PUT describes the whole resource, so fields you leave out may be wiped. PATCH carries only the change, typically as JSON Merge Patch (RFC 7396) or as a list of operations in JSON Patch (RFC 6902). An operation such as “append an item to this list” adds two items if applied twice, which is why PATCH is not considered idempotent.
When a resource does not support a method, the server should answer 405 Method Not Allowed with an Allow header listing the methods it does accept; a method the server does not recognize at all warrants 501 Not Implemented. See HTTP status codes for the other responses, and the methods section of RFC 9110 for the normative definitions.