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

Every HTTP request carries a method — GET, POST, PUT, PATCH, DELETE, and a few less common ones — that tells the server what kind of operation the client is asking for. In principle these are simple, well-defined verbs. In practice, a huge number of real-world APIs use them inconsistently: a POST endpoint that actually updates an existing resource, a PUT that only changes one field, a GET that has side effects it shouldn't have. Understanding what each method is actually supposed to mean — not just what a specific API happens to do with it — makes it much easier to design a clean API, debug someone else's, and spot the kind of REST-convention violations that quietly cause bugs around caching, retries and browser behavior.

The five methods you'll use almost all the time

• GET — retrieve a resource, with no side effects. A GET request should be safe to make repeatedly without changing anything on the server; browsers, proxies and caches all rely on this assumption being true.
• POST — create a new resource, or trigger an action that doesn't map cleanly to a specific existing resource (submitting a form, triggering a process). POST is the one method that's neither safe nor idempotent by convention.
• PUT — replace an entire resource at a known location with the data provided. A PUT should be idempotent: sending the exact same PUT request multiple times should leave the resource in the same final state as sending it once.
• PATCH — apply a partial update to a resource, changing only the fields included in the request rather than replacing the whole thing. This is the method most often confused with PUT.
• DELETE — remove a resource. Like PUT, a well-behaved DELETE is idempotent: deleting an already-deleted resource should be a no-op (or a consistent, predictable response), not an error that behaves differently each time.

Where the method actually goes in a real request

The method sits at the very start of an HTTP request line, alongside the path and protocol version — `GET /api/orders/42 HTTP/1.1` — and is functionally distinct from the URL path itself, which is a common early source of confusion for anyone new to building APIs. Two requests can hit the exact same path (`/api/orders/42`) and mean completely different things depending purely on the method: GET reads that order, PUT replaces it, DELETE removes it. This is also exactly why REST-style API design leans on having relatively few, predictable URL patterns and lets the method carry the meaning of the operation, rather than encoding the action into the URL itself (an older, less RESTful style might use separate URLs like `/getOrder`, `/updateOrder`, `/deleteOrder` for the same resource) — the method-carries-the-verb convention is what makes a well-designed REST API's surface area smaller and more predictable once you understand the pattern.

Safe vs idempotent — the two properties that actually matter

These two words get thrown around loosely, but they mean specific, different things, and both matter for how a client, browser or proxy is allowed to treat a request.

• Safe means the request doesn't change server state at all. GET is the only common method that's meant to be safe — a GET request existing purely to retrieve data is exactly why browsers pre-fetch links, cache GET responses, and retry failed GETs automatically without asking.
• Idempotent means sending the same request multiple times produces the same end state as sending it once, even if the individual responses differ slightly. GET, PUT and DELETE are all meant to be idempotent. POST is explicitly *not* — sending the same POST twice is expected to potentially create two resources, not update the first one, which is exactly why double-clicking a "submit" button on a poorly-built form can create duplicate orders.
• PATCH's idempotency depends on what the patch actually contains — setting a field to a fixed value ("set status to 'shipped'") is idempotent; an instruction like "increment the counter by 1" is not, since repeating it changes the result each time. This is a subtlety a lot of PATCH implementations don't handle carefully.

PUT vs PATCH — the mix-up that causes the most confusion

These two are semantically close enough that plenty of APIs use them interchangeably, which is exactly the source of the confusion. The distinction that matters: PUT means "here is the complete, new state of this resource — replace whatever's there with exactly this," while PATCH means "here are the specific changes to apply — leave everything else untouched." Sending a PUT request with only three of a resource's ten fields, expecting the other seven to stay unchanged, is a genuinely common bug — by REST convention, a proper PUT implementation should treat the missing fields as being cleared or reset, not preserved, because PUT is a full replacement, not a partial update. If you only mean to change one field, PATCH is the semantically correct method; using PUT for that purpose either requires you to resend every field every time (fetching the current resource first just to send it back with one change) or relies on a non-standard, PUT-with-partial-data implementation that will confuse any client expecting standard REST behaviour.

Where POST fits in when the semantics get fuzzy

POST is the method most APIs reach for when an action doesn't map cleanly to "replace this resource" or "partially update this resource" — creating a new order, triggering a password reset email, processing a payment, running a search with a complex query body too large for a URL. Because POST carries no safety or idempotency guarantee by convention, it's also the method where API designers most often need to build their own safeguards against duplicate submissions — an idempotency key sent by the client and checked server-side is a common pattern specifically for POST endpoints where an accidental duplicate request (a network retry, a double-click) would otherwise create a duplicate resource, since the protocol itself won't protect against that the way it implicitly does for PUT and DELETE.

A few less common but still important methods

• HEAD — identical to GET but returns only the headers, no response body. Useful for checking whether a resource exists, or its size/last-modified date, without downloading the full content.
• OPTIONS — asks the server what methods and headers are allowed for a given endpoint, without performing any action. Browsers automatically send this as a CORS 'preflight' request before certain cross-origin requests, to check the server permits them.
• TRACE and CONNECT — rarely used directly in typical web application development; TRACE echoes back the received request for debugging purposes and is frequently disabled for security reasons, while CONNECT is mainly used to establish tunnelled connections through proxies.

How this connects to status codes

The method you send and the status code you get back are closely related in a well-designed API — a successful POST that creates a resource conventionally returns 201 Created (often with a Location header pointing to the new resource), while a successful PUT, PATCH or DELETE more commonly returns 200 OK with the updated resource, or 204 No Content when there's deliberately nothing to send back. A GET that finds nothing returns 404, not an empty 200 — returning 200 with an empty or null body for a resource that doesn't exist is a common API design mistake that makes client-side error handling unnecessarily awkward, since the client has to inspect the body to discover a failure the status code should have communicated directly.

How this shows up in everyday tools, not just backend code

Understanding HTTP methods isn't purely academic backend knowledge — it surfaces directly in tools most developers use daily. Browser DevTools' Network tab shows the method for every request a page makes, which is often the fastest way to spot a bug where a form is unexpectedly submitting via GET instead of POST (visible instantly as query parameters appearing in the URL bar with sensitive form data attached, rather than tucked away in a request body). API testing tools like Postman or a plain `curl` command require you to explicitly set the method for anything other than a simple GET — `curl -X PUT` or `curl -X DELETE` — and a surprising number of "my API call isn't working" debugging sessions turn out to be someone forgetting that flag and accidentally sending a default GET against an endpoint that only accepts POST. A JSON formatter is often the next stop once you've confirmed the method is right and just need to inspect or clean up the actual request or response body.

What happens when you use the wrong method — the 405 response

A well-built API endpoint should explicitly reject requests using a method it doesn't support, returning 405 Method Not Allowed rather than silently accepting the request or returning a confusing, unrelated error. A 405 response is also required by the HTTP spec to include an Allow header listing which methods *are* actually supported at that endpoint — which is genuinely useful for debugging, since it tells the client exactly what to try instead rather than leaving them guessing. Seeing a 405 while integrating with someone else's API is a strong, specific signal: you're hitting a real, existing endpoint (unlike a 404, which means the URL itself is wrong), but with the wrong verb — check the API's documentation for which method that specific endpoint actually expects, since it's a common enough mix-up (POST-ing to an endpoint that only accepts PUT, for instance) that most API documentation states the expected method explicitly right next to each endpoint's URL.

REST conventions vs RPC-style APIs, briefly

Everything above describes REST convention, where HTTP methods map onto CRUD-style operations (Create/Read/Update/Delete) against resources identified by URLs. Not every API follows this — RPC-style APIs (including most GraphQL APIs, and many gRPC or JSON-RPC-based services) often use a single HTTP method, almost always POST, for essentially every operation, with the actual action specified inside the request body rather than through the HTTP method itself. Neither approach is objectively wrong — REST's method-per-operation convention makes an API's capabilities somewhat self-documenting and lets HTTP-level tooling (caching, browser behaviour) work as intended, while an RPC-style approach can be simpler to implement for APIs whose operations don't map cleanly onto CRUD-on-a-resource in the first place. Knowing which style an API you're integrating with follows matters before assuming REST conventions apply — sending a PATCH to a GraphQL endpoint (which almost universally expects POST regardless of the underlying operation) won't work the way REST intuition would predict.

A quick reference for choosing the right method

• Reading data with no side effects → GET
• Creating a new resource where the server assigns the ID → POST
• Creating or fully replacing a resource at a client-known location/ID → PUT
• Updating only some fields of an existing resource → PATCH
• Removing a resource → DELETE
• Triggering an action that isn't really about a specific resource (send an email, run a report, process a webhook) → POST

The short version: GET reads without side effects, POST creates or triggers with no idempotency guarantee, PUT replaces a whole resource, PATCH changes part of one, and DELETE removes it — with PUT and DELETE both expected to be safely repeatable. Most real API bugs around this area come from either attaching side effects to GET, or reaching for PUT when PATCH's partial-update semantics were actually what was meant. Getting the method right isn't pedantry — it's what lets browsers, proxies, caches and API clients make correct assumptions about your endpoint's behaviour without you having to document every edge case by hand.