Interactive reference for all HTTP request methods. Learn GET, POST, PUT, PATCH, DELETE, and more. Filter by safety, idempotency, and cacheability. Copy examples instantly.
Retrieve a representation of the target resource. GET requests should only retrieve data and have no other effect. The most commonly used HTTP method.
GET /api/users/42 HTTP/1.1 Host: api.example.com Accept: application/json --- Response --- HTTP/1.1 200 OK Content-Type: application/json { "id": 42, "name": "Ada Lovelace" }
Submit an entity to the specified resource, often causing a change in state or side effects on the server. Used to create new resources or trigger actions.
POST /api/users HTTP/1.1 Host: api.example.com Content-Type: application/json { "name": "Grace Hopper", "role": "admin" } --- Response --- HTTP/1.1 201 Created Location: /api/users/43
Replace all current representations of the target resource with the request payload. Creates the resource if it does not exist (when client knows the target URI).
PUT /api/users/42 HTTP/1.1 Host: api.example.com Content-Type: application/json { "id": 42, "name": "Ada Lovelace", "role": "admin" } --- Response --- HTTP/1.1 200 OK
Apply partial modifications to a resource. Unlike PUT which replaces the entire resource, PATCH carries a set of instructions describing how to modify the resource.
PATCH /api/users/42 HTTP/1.1 Host: api.example.com Content-Type: application/json { "role": "editor" } --- Response --- HTTP/1.1 204 No Content
Remove the specified resource from the server. The URI should map to a single resource, not a collection. Deleting the same resource multiple times has the same effect.
DELETE /api/users/42 HTTP/1.1 Host: api.example.com --- Response --- HTTP/1.1 204 No Content
Identical to GET but transfers the status line and header section only, without a message body. Useful for checking resource existence, size, or modification time without downloading.
HEAD /api/users/42 HTTP/1.1 Host: api.example.com --- Response --- HTTP/1.1 200 OK Content-Type: application/json Content-Length: 42 Last-Modified: Mon, 11 May 2026 10:00:00 GMT
Describe the communication options for the target resource. Returns supported methods, CORS headers, and other capabilities. Widely used for CORS preflight requests.
OPTIONS /api/users HTTP/1.1 Host: api.example.com Origin: https://app.example.com --- Response --- HTTP/1.1 204 No Content Allow: GET, POST, HEAD, OPTIONS Access-Control-Allow-Origin: *
Perform a message loop-back test along the path to the target resource. Echoes back the received request so the client can see what intermediate servers are adding or changing.
TRACE /api/users HTTP/1.1 Host: api.example.com --- Response --- HTTP/1.1 200 OK Content-Type: message/http TRACE /api/users HTTP/1.1 Host: api.example.com
Establish a tunnel to the server identified by the target resource. Primarily used with proxies to create an end-to-end encrypted connection (e.g., HTTPS through an HTTP proxy).
CONNECT api.example.com:443 HTTP/1.1 Host: api.example.com:443 Proxy-Authorization: Basic dXNlcjpwYXNz --- Response --- HTTP/1.1 200 Connection Established
| Aspect | PUT | PATCH |
|---|---|---|
| Operation | Full replacement of the resource | Partial modification of the resource |
| Payload | Complete resource representation | Only fields to change (diff/patch format) |
| Missing fields | Omitted fields are deleted/reset | Omitted fields remain unchanged |
| Idempotent | Yes — same PUT always same result | Not guaranteed — depends on patch format |
| Safe | No | No |
| Use when | Client knows the full state and URI | Client only has partial updates |
| Example | Replace user profile entirely | Change just the user's email |
Use plural nouns for collections. Avoid verbs in URLs.
GET /api/users — list all users
POST /api/users — create a new user
Use IDs to identify specific resources under a collection.
GET /api/users/42 — get user 42
PUT /api/users/42 — replace user 42
DELETE /api/users/42 — delete user 42
Represent relationships through URL nesting.
GET /api/users/42/orders — list user's orders
POST /api/users/42/orders — create order for user
Use query parameters, not new endpoints.
?status=active&sort=name&limit=10
?fields=id,name,email — sparse fieldsets
Choose one strategy and stick to it.
/api/v2/users — URL path
Accept: application/vnd.api+json;v=2 — header
Never use GET for state changes.
Avoid /api/getUser — HTTP method is the verb.
Don't return 200 for errors — use proper 4xx/5xx.