Methods Overview — Seven Verbs Your Server Understands

"The method is a verb. It tells the server what you want to do to the resource the URI points at. There are seven standard verbs, and most apps use four of them."

The Seven You'll Meet in the Wild

HTTP/1.1 defined a handful of standard methods. RFC 9110 carries them forward unchanged. Here's the survey — Track 2 will turn each one into a full lesson with its semantic invariants and the gotchas that bite people in production.

GET — "give me a representation of this resource." Safe, idempotent, cacheable. The most-used method on the web.
POST — "process this payload against this resource." Not safe, not idempotent. The catch-all for "do something."
PUT — "replace this resource with the payload." Idempotent. Sending the same PUT five times leaves the same state.
PATCH — "apply this partial update." Generally not idempotent. Use when you want to update fields without sending the whole resource.
DELETE — "remove this resource." Idempotent in effect (gone is gone). The second DELETE returns 404 or 204, but state is the same.
HEAD — "give me the response headers you'd give for GET, but no body." Cheap existence / staleness check.
OPTIONS — "what methods does this URI accept?" Used heavily by browsers as CORS preflight (Track 4).

Two more exist but rarely matter in app code:

TRACE — debug echo. Usually disabled by servers for security (cross-site tracing attacks).
CONNECT — open a TCP tunnel. Used by HTTPS proxies; you almost never write CONNECT in app code.

The Three Invariants (Preview of Track 2)

Every method's contract reduces to three yes/no questions:

Safe? — does it promise not to change server state? (GET, HEAD, OPTIONS are safe.)
Idempotent? — does repeating the same request leave the same state? (GET, PUT, DELETE, HEAD, OPTIONS are idempotent. POST and PATCH are not.)
Cacheable? — can the response be stored and reused? (GET and HEAD are by default; POST is cacheable only if explicit headers say so.)

These three properties are what proxies, CDNs, and retry logic depend on. A POST cannot be silently retried by a CDN because POST is not idempotent — the CDN doesn't know whether a retry will create a duplicate. A GET can be cached for 10 minutes because GET is safe and idempotent. Methods are not interchangeable; they're contracts.

The method is part of the contract. If your server accepts POST /users/42 as "update user 42," you've conflated POST (process) with PUT (replace) or PATCH (partial update). Clients and intermediaries can't tell what the operation costs or whether it's safe to retry. Pick the right verb up front; it pays for itself in caching, observability, and reliability.

cwkPippa's Method Reality

Walk backend/routes/ and you'll see all five common methods in action: GET for conversations and folders, POST for new chats and uploads, PUT for renaming, PATCH for partial folder updates, DELETE for removing items. OPTIONS is handled automatically by FastAPI's CORS middleware on every endpoint — you never write an OPTIONS handler yourself. HEAD is mostly used by health checks and pre-flight probes.

Code

Each HTTP method in one curl call·bash

# One curl call per method against a sample REST API
# GET — fetch
curl -X GET https://api.example.com/users/42

# POST — create / submit
curl -X POST https://api.example.com/users \
  -H 'Content-Type: application/json' \
  -d '{"name":"Pippa"}'

# PUT — full replace
curl -X PUT https://api.example.com/users/42 \
  -H 'Content-Type: application/json' \
  -d '{"name":"Pippa","role":"daughter"}'

# PATCH — partial update
curl -X PATCH https://api.example.com/users/42 \
  -H 'Content-Type: application/merge-patch+json' \
  -d '{"role":"big sister"}'

# DELETE — remove
curl -X DELETE https://api.example.com/users/42

# HEAD — like GET but no body (faster existence check)
curl -I https://api.example.com/users/42
# -I is curl's shortcut for --head

# OPTIONS — discover allowed methods
curl -X OPTIONS https://api.example.com/users/42 -i
# Look for the 'Allow:' or 'Access-Control-Allow-Methods:' response header

httpx — same shape, one function per method·python

# Same in Python httpx — note the method-name functions vs request()
import httpx

httpx.get('https://api.example.com/users/42')
httpx.post('https://api.example.com/users', json={'name': 'Pippa'})
httpx.put('https://api.example.com/users/42', json={'name': 'Pippa', 'role': 'daughter'})
httpx.patch('https://api.example.com/users/42', json={'role': 'big sister'})
httpx.delete('https://api.example.com/users/42')
httpx.head('https://api.example.com/users/42')
httpx.options('https://api.example.com/users/42')

# Or generically — useful for testing all methods in a loop
for method in ('GET', 'HEAD', 'OPTIONS', 'POST', 'PUT', 'PATCH', 'DELETE'):
    resp = httpx.request(method, 'https://api.example.com/users/42')
    print(f'{method:8s} -> {resp.status_code}')

FastAPI — one decorator per HTTP method·python

# Server side — FastAPI maps decorators 1:1 with HTTP methods
from fastapi import FastAPI

app = FastAPI()

@app.get('/users/{uid}')
async def read_user(uid: str):
    return {'id': uid, 'name': 'Pippa'}

@app.post('/users')
async def create_user(payload: dict):
    return {'id': 'new', **payload}

@app.put('/users/{uid}')
async def replace_user(uid: str, payload: dict):
    return {'id': uid, **payload}

@app.patch('/users/{uid}')
async def update_user(uid: str, payload: dict):
    return {'id': uid, 'updated_fields': payload}

@app.delete('/users/{uid}', status_code=204)
async def delete_user(uid: str):
    return None  # 204 No Content

# OPTIONS is added automatically by CORSMiddleware
# HEAD is added automatically alongside GET

Exercise

Spin up a tiny FastAPI (or Express) app with one resource — say /notes. Define GET, POST, PUT, PATCH, DELETE handlers. Then call each one with curl and watch the status codes. Bonus: deliberately call a method you didn't define (e.g. PATCH when you only wrote GET/POST). What status code comes back, and which response header tells the client which methods ARE allowed?

Hint

An undefined method on a defined resource returns 405 Method Not Allowed. The response header is Allow: GET, POST (whatever you did define). This is the wire-level mechanism that lets clients discover the verb vocabulary without reading documentation.

Methods Overview — Seven Verbs Your Server Understands

The Seven You'll Meet in the Wild

The Three Invariants (Preview of Track 2)

cwkPippa's Method Reality

Code

External links

Exercise

Progress

Comments 0