HTTP request methods explained: GET, POST, PUT, DELETE & more

Every HTTP request does something — and the method is the verb that says what. HTTP defines a set of request methods to indicate the purpose of the request and what you expect if it succeeds. Methods are sometimes called "HTTP verbs", though they can also be nouns. This article explains each one in plain terms.

The quick list

The ones you will use constantly are GET, POST, PUT, PATCH and DELETE — the everyday "CRUD" building blocks of web APIs.

GET: fetch a resource

GET requests a representation of the specified resource. It should only retrieve data and should not have a request body — sending one is undefined behavior that some servers reject with a client error.

A browser sends GET every time you open a page or image. Because it only reads, GET is safe, idempotent and cacheable: you can repeat it and cache the response.

HEAD: the headers, not the content

HEAD asks for a response identical to a GET, but without the body. It is the cheap version of GET — often used to check a resource before downloading it. For example, if a URL might produce a large download, a HEAD request can read the Content-Length header to check the file size first.

POST: send data that changes something

POST sends data to the server. The Content-Type header describes the body's type. HTML forms typically send data with POST, and this usually results in a change on the server.

The key difference from PUT: POST is not idempotent. Repeating the same POST may create the same order, the same message, or the same entry several times.

PUT: create or replace, fully

PUT creates a new resource or replaces the representation of the target resource with the request content — a complete replacement. It is idempotent: calling it once is no different from calling it several times. The fourth identical PUT leaves the resource exactly as the first did.

PATCH: partial modification

PATCH applies a partial modification to a resource. It is analogous to the "update" in CRUD — but note that HTTP is not the same as CRUD, and the two should not be confused.

Think of the difference this way: a PUT is a complete replacement, while a PATCH is a set of instructions for modification. A PUT is always idempotent. A PATCH may not be — for instance, if a resource has an auto-incrementing counter, a PUT overwrites the counter (it replaces the whole resource) and repeating it is stable, whereas a PATCH that increments a counter changes the value each time it is applied.

DELETE: remove a resource

DELETE asks the server to delete the specified resource. Like GET, it should not have a body. It is idempotent — deleting the same resource again is "no different" from deleting it once (the resource is gone).

OPTIONS: what am I allowed to do?

OPTIONS asks for the permitted communication options for a given URL or server. You can use it to test which HTTP methods a request allows, or whether a request would succeed. Browsers use it behind the scenes for CORS: a "preflight" OPTIONS request checks whether a cross-origin request is allowed before the real request is sent. A special form, OPTIONS *, refers to the entire server rather than one path.

CONNECT and TRACE

Two you rarely see directly:

• CONNECT establishes a tunnel to the server — this is how HTTPS traffic gets carried through an HTTP proxy.
• TRACE performs a message loop-back test along the path, letting the client see what the server received. For security reasons, many servers disable it.

Safe, idempotent, cacheable — what these actually mean

These three properties decide whether it is safe to repeat or cache a request:

• Safe — the method does not change the server state. A request using a safe method can be made repeatedly with no side effects. GET, HEAD, OPTIONS and TRACE are safe; POST, PUT, DELETE, PATCH and CONNECT are not.
• Idempotent — repeating the request produces the same result as doing it once. GET, HEAD, PUT, DELETE, OPTIONS and TRACE are idempotent; POST and PATCH are not guaranteed to be.
• Cacheable — the response may be stored and reused. GET and HEAD are cacheable. POST and PATCH are only cacheable when the response explicitly includes freshness information and a matching Content-Location header. The others are not cacheable.

When to use which

• Reading a page, image or API data → GET.
• Checking something exists or its size without downloading it → HEAD.
• Creating an item in a collection → POST (or PUT when you supply the full resource).
• Updating/replacing a whole resource → PUT.
• Updating part of a resource → PATCH.
• Removing a resource → DELETE.

Why idempotency matters in practice: retries. If a request times out and you are not sure it arrived, an idempotent method can be safely repeated. This is why payment and order APIs lean on idempotency — repeating a POST that creates a charge twice could double-charge someone.

FAQ

What is the difference between GET and POST?

GET requests a representation of a resource and should only retrieve data — it is safe, idempotent and cacheable, so you can repeat it without side effects. POST sends data to the server and usually causes a change or side effect, and it is not idempotent: repeating the same POST can create the same order or entry several times. As a rule, read with GET and send data that changes something with POST.

What does it mean when an HTTP method is idempotent?

An idempotent method produces the same result whether you call it once or many times. For example PUT replaces the whole resource, so a fourth identical PUT leaves it exactly as the first did. This matters for retries: if a request times out and you are not sure it arrived, an idempotent method can be safely repeated — which is why payment and order APIs rely on idempotency, since repeating a POST that creates a charge could double-charge someone.

What is the difference between PUT and PATCH?

PUT replaces the entire resource with the request content — a complete replacement, and always idempotent. PATCH applies a partial modification, like the "update" step of CRUD, and may not be idempotent. For example, if a resource has an auto-incrementing counter, PUT overwrites the counter (it replaces the whole resource) while a PATCH that increments the counter changes the value every time it runs.

How do I find out which methods a server allows?

Send an OPTIONS request. OPTIONS asks for the communication options the target supports, so you can test which HTTP methods a request allows or whether it would succeed. Browsers also use it for CORS: a "preflight" OPTIONS request checks whether a cross-origin request is allowed before the real request is sent.

Summary

HTTP request methods are the verbs of the web: GET fetches, HEAD checks, POST sends and creates, PUT replaces, PATCH updates partially, and DELETE removes. The properties safe, idempotent and cacheable tell you whether a method can be repeated or cached without consequences. Understand those three words and you can reason about any API, framework or server log you meet.