HTTP Methods

Definition

HTTP methods (also called HTTP verbs) define what action you want to perform on a resource. Think of them as the verbs in a sentence - the URL tells you what (the noun/resource), and the method tells you the action (the verb).

The main HTTP methods map beautifully to CRUD operations: GET (read), POST (create), PUT/PATCH (update), DELETE (delete). Each method has specific semantics - GET requests should be safe (no side effects), PUT/DELETE should be idempotent (same result if repeated), and POST can create new resources.

While HTTP defines nine methods, RESTful APIs primarily use five: GET, POST, PUT, PATCH, and DELETE. Others like HEAD, OPTIONS, and TRACE serve specific purposes. Understanding which method to use and why is fundamental to designing clean, intuitive APIs.

Example

Blog API - Full CRUD:

• GET /posts - List all blog posts
• GET /posts/123 - Read specific post
• POST /posts - Create new post
• PUT /posts/123 - Replace entire post
• PATCH /posts/123 - Update part of post (title only)
• DELETE /posts/123 - Delete post

E-commerce Cart:

• GET /cart - View cart contents
• POST /cart/items - Add item to cart
• PATCH /cart/items/456 - Update quantity
• DELETE /cart/items/456 - Remove item
• DELETE /cart - Clear entire cart

User Management:

• GET /users?role=admin - List admin users
• POST /users - Create new user account
• PUT /users/789 - Update full user profile
• PATCH /users/789 - Change password only
• DELETE /users/789 - Deactivate account

Analogy

TV Remote Control: HTTP methods are like buttons on a remote:

• GET = INFO button (shows information, doesn’t change anything)
• POST = RECORD button (creates a new recording)
• PUT = PRESET button (replaces entire preset configuration)
• PATCH = VOLUME+ (changes one aspect)
• DELETE = ERASE button (removes a recording)

Library Card System:

• GET = Browse books (just looking, doesn’t change inventory)
• POST = Request new book (creates new loan record)
• PUT = Renew loan (replaces old due date with new one)
• PATCH = Extend due date by 2 weeks (partial update)
• DELETE = Return book (removes loan record)

Code Example

// GET - Retrieve resource (safe, idempotent)
GET /api/users/123 HTTP/1.1
Host: api.example.com

// POST - Create resource (not idempotent)
POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "Alice", "email": "[email protected]"}

// PUT - Replace resource (idempotent)
PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{"name": "Alice Smith", "email": "[email protected]", "role": "admin"}

// PATCH - Partial update (idempotent)
PATCH /api/users/123 HTTP/1.1
Content-Type: application/json

{"email": "[email protected]"}

// DELETE - Remove resource (idempotent)
DELETE /api/users/123 HTTP/1.1

// OPTIONS - Discover allowed methods
OPTIONS /api/users/123 HTTP/1.1
// Response: Allow: GET, PUT, PATCH, DELETE

// HEAD - Get metadata without body
HEAD /api/users/123 HTTP/1.1
// Response: headers only, no body

Diagram

graph TD
A[HTTP Methods] --> B[Safe Methods]
A --> C[Unsafe Methods]
B --> D[GET]
B --> E[HEAD]
B --> F[OPTIONS]
C --> G[Idempotent]
C --> H[Non-Idempotent]
G --> I[PUT]
G --> J[DELETE]
G --> K[PATCH*]
H --> L[POST]

Best Practices

1. Use GET for reading data (never modify with GET)
2. Use POST for creating new resources
3. Use PUT for full replacement, PATCH for partial updates
4. Use DELETE for removing resources
5. Return appropriate status codes (201 for POST, 204 for DELETE)
6. Make PUT, PATCH, DELETE idempotent
7. Keep GET requests safe (no side effects)
8. Support OPTIONS for CORS preflight
9. Use POST for complex operations that don’t fit CRUD
10. Document which methods each endpoint supports

Common Mistakes

Using GET for actions that modify data, using POST for everything, confusing PUT and PATCH, returning 200 OK for DELETE instead of 204 No Content, not implementing idempotency for PUT/DELETE, forgetting to handle OPTIONS for CORS, using DELETE with request body (some servers ignore it).

Standards & RFCs

Related Terms