Working with HTTP Methods
1. Using GET Method
| Property | Value |
|---|
| Purpose | Retrieve resource representation |
| Safe | Yes (no side effects) |
| Idempotent | Yes |
| Cacheable | Yes |
| Body | Should not have request body |
| Success | 200 OK, 304 Not Modified |
| Failure | 404, 401, 403 |
Example: GET Request
GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGc...
2. Using POST Method
| Property | Value |
|---|
| Purpose | Create resource, non-idempotent action |
| Safe | No |
| Idempotent | No (default) |
| Cacheable | Only with explicit headers |
| Body | Required (resource representation) |
| Success | 201 Created (with Location header), 200 OK, 202 Accepted |
Example: POST Create User
POST /api/users HTTP/1.1
Content-Type: application/json
{"name": "Alice", "email": "alice@example.com"}
HTTP/1.1 201 Created
Location: /api/users/43
Content-Type: application/json
{"id": 43, "name": "Alice", "email": "alice@example.com"}
3. Using PUT Method
| Property | Value |
|---|
| Purpose | Full replacement of resource (or create at known URI) |
| Idempotent | Yes (same body → same state) |
| Body | Complete resource representation |
| Success | 200 OK (updated), 201 Created (new), 204 No Content |
Warning: PUT replaces the ENTIRE resource. Omitted fields may be set to null/default. Use PATCH for partial updates.
4. Using PATCH Method
| Property | Value |
|---|
| Purpose | Partial update |
| Idempotent | Depends on patch semantics (JSON Merge: yes; JSON Patch: usually yes) |
| Body Format | JSON Merge Patch (RFC 7396), JSON Patch (RFC 6902) |
| Content-Type | application/merge-patch+json or application/json-patch+json |
| Success | 200 OK, 204 No Content |
Example: JSON Merge Patch
PATCH /api/users/42 HTTP/1.1
Content-Type: application/merge-patch+json
{"email": "newalice@example.com"}
5. Using DELETE Method
| Property | Value |
|---|
| Purpose | Remove resource |
| Idempotent | Yes (deleting deleted = same state) |
| Body | Usually empty |
| Success | 204 No Content (most common), 200 OK (with body), 202 Accepted (async) |
| Repeat | Returns 404 or 204 (both valid) |
6. Using HEAD Method
| Property | Value |
|---|
| Purpose | Same as GET but returns headers only (no body) |
| Use Cases | Check existence, get metadata (Content-Length, ETag), validate cache |
| Idempotent / Safe | Yes / Yes |
| Success | 200 OK (headers only) |
7. Using OPTIONS Method
| Property | Value |
|---|
| Purpose | Discover allowed methods, CORS preflight |
| Response Header | Allow: GET, POST, PUT, DELETE |
| CORS | Browsers send before non-simple cross-origin requests |
8. Understanding Safe Methods
Safe methods do not modify server state (read-only).
| Method | Safe | Idempotent |
|---|
| GET | Yes | Yes |
| HEAD | Yes | Yes |
| OPTIONS | Yes | Yes |
| PUT | No | Yes |
| DELETE | No | Yes |
| PATCH | No | Usually |
| POST | No | No |
9. Understanding Idempotent Methods
Idempotent: N identical requests produce the same server state as 1 request.
Note: Idempotency refers to server state, not the response. A second DELETE may return 404 instead of 204; state is still the same (resource gone).
| Scenario | Use Method |
|---|
| Network retries safe | GET, PUT, DELETE |
| Need uniqueness guarantee | POST + Idempotency-Key header |
10. Handling Method Override
For clients that only support GET/POST (older browsers, firewalls), tunnel other methods via header.
| Header | Effect |
|---|
X-HTTP-Method-Override: PUT | Server treats POST as PUT |
X-HTTP-Method-Override: DELETE | Server treats POST as DELETE |
?_method=PATCH (query) | Alternate (Rails-style) |
Warning: Only enable for trusted clients; can bypass method-based security rules.