HTTP Methods Explained: GET, POST, PUT, PATCH, DELETE

HTTP methods are verbs that tell a server what kind of action a request wants performed on a resource — the same URL can behave completely differently depending on whether the request arrives as a GET, a POST, or a DELETE. The method isn’t just a label; it carries specific guarantees about safety, idempotency, and cacheability that well-behaved clients, proxies, and servers all rely on. Using the wrong one doesn’t just look sloppy — it breaks assumptions caching layers and browsers make automatically.

The core methods

GET requests a representation of a resource and should never change server-side state. It’s the default method browsers use for navigation, and it’s the only method most caching infrastructure aggressively caches by default, precisely because a GET is expected to be safe and repeatable with no side effects.

POST submits data to be processed, typically creating a new resource or triggering an action that isn’t a simple retrieval — placing an order, submitting a form, starting a batch job. Unlike GET, a POST is not expected to be safe or idempotent: sending the same POST twice can create two resources instead of one, which is exactly why browsers warn you before resubmitting a form.

PUT replaces a resource entirely at a known URL. A PUT request’s body represents the complete state the resource should have afterward — if you omit a field the resource previously had, a fully spec-compliant PUT treats that as removing it, because the request describes the whole target state, not a partial change.

PATCH applies a partial update to a resource — you send only the fields that should change, and everything else stays as it was. This is the method most REST APIs actually mean when developers loosely say “update,” since sending an entire resource just to change one field is often wasteful and race-condition-prone.

DELETE removes a resource at a given URL. Calling it again on an already-deleted resource is expected to be harmless — the resource is gone either way, which is what makes DELETE idempotent even though it’s not safe.

Safety and idempotency

These two properties are what actually govern how a method should be used, and they’re independent of each other:

• Safe methods don’t change server state. Only GET, HEAD, and OPTIONS are safe. A safe method should be something a browser, a link crawler, or a proxy can call without asking permission, because nothing changes as a result.
• Idempotent methods produce the same end state no matter how many times they’re repeated with the same input. GET, PUT, and DELETE are idempotent. POST and PATCH generally are not, though a specific PATCH implementation can be made idempotent if it’s designed that way (setting a field to an absolute value rather than incrementing it, for instance).

This is why idempotency matters so much for retry logic: a client that isn’t sure whether its PUT or DELETE request actually reached the server can safely retry it, because repeating it changes nothing further. Retrying an unacknowledged POST carries real risk of duplicating the action, which is why APIs that need safe retries on POST typically add their own idempotency-key mechanism on top of HTTP rather than relying on the method itself.

Method comparison

Method	Safe	Idempotent	Typical use	Has a request body
GET	Yes	Yes	Retrieve a resource	No
POST	No	No	Create a resource, trigger an action	Yes
PUT	No	Yes	Replace a resource entirely	Yes
PATCH	No	Not guaranteed	Partially update a resource	Yes
DELETE	No	Yes	Remove a resource	Usually no

How this connects to status codes

The method a request used shapes which HTTP status code is the correct response. A successful POST that creates a resource conventionally returns 201 Created with a Location header pointing at the new resource, rather than the generic 200 OK a successful GET returns. A DELETE that succeeds with nothing further to report often returns 204 No Content. Getting the method and status code combination right is part of what makes an API predictable to consume without reading its documentation for every single endpoint.

Methods in REST vs other API styles

REST APIs lean heavily on HTTP methods to express intent, mapping CRUD operations directly onto GET/POST/PUT/PATCH/DELETE against resource URLs — see what a REST API actually is for how that mapping is meant to work in practice. Other styles handle this differently: GraphQL sends nearly everything over POST, with the actual operation (query or mutation) specified in the request body rather than the HTTP method, and gRPC abstracts HTTP methods away entirely behind generated service calls. Neither is wrong — they’re just choosing not to lean on HTTP’s method semantics the way REST does.

Where methods and browsers interact

Browsers enforce method-related behavior directly. Simple cross-origin GET and POST requests can trigger a CORS preflight OPTIONS request when they use non-standard headers or certain content types, while PUT, PATCH, and DELETE almost always trigger a preflight regardless — the browser is checking with the server, using the safe OPTIONS method, whether the actual request is permitted before sending anything that could have a side effect on a different origin.

The takeaway

HTTP methods aren’t interchangeable labels — each one carries specific guarantees about whether it’s safe to call automatically and whether it’s safe to retry blindly. GET reads without side effects, POST creates or triggers without idempotency guarantees, PUT replaces a resource wholesale, PATCH updates it partially, and DELETE removes it idempotently. Picking the method that matches what a request actually does — rather than defaulting to POST for everything — is what lets caches, retries, and browser security checks behave the way they’re designed to.