HTTP Methods
GET, POST, PUT, PATCH, DELETE and friends each declare an intent. Learn what every method means and when to reach for it.
Prerequisites: HTTP Request and Response
Learning objectives
- Name the common HTTP methods and the intent each one signals.
- Distinguish safe methods from idempotent methods and place each verb correctly.
- Decide when a request needs a body and which methods typically carry one.
- Map CRUD operations onto HTTP methods in a REST API.
Simple explanation
Every HTTP request starts with a verb that announces what you want to *do*. Think of walking into a warehouse and telling the clerk your intent up front: *"I just want to look"* (GET), *"add this new box"* (POST), *"replace the whole shelf"* (PUT), *"change one label"* (PATCH), or *"throw this out"* (DELETE). The address (the URL) says *which* thing; the method says *what* to do with it.
That single word matters. It tells caches whether they can store the answer, tells proxies whether it's safe to retry, and tells other developers what your endpoint is for — all before the server reads a single byte of the body.
Technical explanation
The core HTTP methods you use every day:
- GET — retrieve a representation of a resource. No body, no side effects.
GET /users/42 - POST — submit data to be processed, usually *creating* a new resource or triggering an action. Carries a body.
POST /users - PUT — replace the target resource entirely with the request body. Carries a body.
PUT /users/42 - PATCH — apply a *partial* update to a resource. Carries a body describing only the changes.
PATCH /users/42 - DELETE — remove the target resource.
DELETE /users/42 - HEAD — like GET, but the server returns only the status and headers, no body. Great for checking existence or metadata cheaply.
- OPTIONS — ask what the server allows for a resource. The response's
Allowheader lists permitted methods; browsers use it for CORS preflight.
Two properties classify these methods:
- A method is safe if it is purely read-only and does not change server state: GET, HEAD, and OPTIONS.
- A method is idempotent if making the same request N times has the same effect as making it once: GET, HEAD, OPTIONS, PUT, and DELETE. POST is *neither* safe nor idempotent — two identical POSTs typically create two resources. PATCH is not guaranteed idempotent (it depends on the patch semantics).
Every safe method is idempotent, but not every idempotent method is safe — PUT and DELETE change state, yet repeating them lands you in the same final state.
Why it matters
The method is a contract. Caches will happily store and replay a GET but never a POST. Load balancers and browsers may automatically retry idempotent requests after a network hiccup, but they must not retry a POST blindly or you could charge a card twice. Choosing the right verb makes your API predictable, cacheable, and safe to operate — choosing the wrong one (say, deleting data on a GET) creates real bugs, because a crawler or prefetcher can trigger it just by following a link.
How it works
When you send a request, the method sits at the very start of the request line:
- The client writes the method, path, and version —
PATCH /users/42 HTTP/1.1. - Middle boxes (caches, proxies, CDNs) inspect the method to decide whether to cache, retry, or forward.
- The server routes on method + path together:
GET /users/42andDELETE /users/42hit the same URL but different handlers. - Methods that carry a body (POST/PUT/PATCH) include a
Content-TypeandContent-Length; the handler parses that body. - The server responds with a status code that fits the verb —
200 OK,201 Createdafter a POST,204 No Contentafter a DELETE, and so on.
Real-world analogy
Picture an office filing cabinet with a clerk. GET is *"show me the file for client 42"* — you read, nothing changes. POST is *"here's a brand-new client, file them and give them the next free number."* PUT is *"throw away folder 42 and put this complete new folder in its place."* PATCH is *"in folder 42, just change the phone number."* DELETE is *"shred folder 42."* HEAD is *"does a folder 42 exist and how thick is it?"* — without pulling the papers out. OPTIONS is *"what am I even allowed to do with this cabinet?"*
Important terminology
- Safe method — a read-only method with no observable effect on server state (GET, HEAD, OPTIONS).
- Idempotent method — repeating the identical request yields the same server state as sending it once (GET, HEAD, OPTIONS, PUT, DELETE).
- Request body / payload — the data sent with a request; standard for POST, PUT, and PATCH, and generally omitted for GET, HEAD, and DELETE.
- CRUD — Create, Read, Update, Delete: the four basic data operations, commonly mapped to POST, GET, PUT/PATCH, and DELETE.
- CORS preflight — an automatic OPTIONS request browsers send before certain cross-origin calls to check what the server permits.
Key definitions
- Safe method
- A read-only method with no side effects on server state — GET, HEAD, and OPTIONS.
- Idempotent method
- A method where repeating the same request leaves the server in the same state — GET, HEAD, OPTIONS, PUT, DELETE.
- PUT vs PATCH
- PUT replaces the entire resource with the body; PATCH applies only a partial, targeted change.
- CRUD to HTTP mapping
- Create→POST, Read→GET, Update→PUT/PATCH, Delete→DELETE — the conventional REST mapping.
Must memorize
Must memorize
- Safe = GET, HEAD, OPTIONS (read-only, no state change).
- Idempotent = GET, HEAD, OPTIONS, PUT, DELETE. POST is neither.
- PUT replaces the whole resource; PATCH updates only part of it.
- Bodies go with POST/PUT/PATCH; GET, HEAD, and DELETE usually have none.
Real-world example
Editing a profile in a REST API
A settings page loads the user with GET /users/42. Changing just the display name sends PATCH /users/42 with { "name": "New Name" } — a partial update. If instead the client submitted the complete profile object to replace the record, it would use PUT /users/42. Deleting the account is DELETE /users/42, which is idempotent: retrying after a dropped connection is safe because the account is already gone.
A CORS preflight with OPTIONS
Before a browser lets a page at app.example.com send DELETE /orders/9 to api.example.com, it first fires an automatic OPTIONS request. The server answers with Access-Control-Allow-Methods: GET, POST, DELETE, and only then does the browser send the real DELETE. The OPTIONS call is safe and changes nothing.
Code example
PATCH /api/users/42 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGci...
{
"email": "ada.new@example.com"
}A PATCH request applying a partial update with a JSON body.
HTTP/1.1 204 No Content
Allow: GET, HEAD, PATCH, PUT, DELETE, OPTIONS
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Origin: https://app.example.comAn OPTIONS response advertising the allowed methods.
// Read — safe, no body
const user = await fetch('/api/users/42').then((r) => r.json());
// Create — POST with a body (not idempotent)
await fetch('/api/users', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: 'Ada Lovelace' }),
});
// Partial update — PATCH with only the changed field
await fetch('/api/users/42', {
method: 'PATCH',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: 'Ada L.' }),
});
// Remove — DELETE, idempotent (safe to retry)
await fetch('/api/users/42', { method: 'DELETE' });Choosing the right method with fetch for each operation.
Common mistakes
Mistake
Using GET (or a query string) to change data, e.g. GET /users/42/delete.
Do this instead
GET must be safe. Use POST/PUT/PATCH/DELETE for changes — crawlers and prefetchers can trigger any GET link.
Mistake
Treating PUT and PATCH as interchangeable and sending a partial object with PUT.
Do this instead
PUT replaces the whole resource, so omitted fields may be wiped. Use PATCH when you only mean to change some fields.
Interview questions
Quiz
Flashcards
Show answer · Space