HTTP Methods

GET and POST are the most commonly used HTTP methods.

GET Request

• Purpose: Retrieve data
• Body: No body (parameters in URL)
• Safe: Yes (doesn't modify data)
• Idempotent: Yes (same result every time)
• Cached: Yes
• Bookmarkable: Yes

GET /api/users?page=1&limit=10 HTTP/1.1
Host: api.example.com
Accept: application/json

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{"users": [{"id": 1, "name": "Alice"}], "total": 50}

POST Request

• Purpose: Create new resource
• Body: Contains data to create
• Safe: No (modifies server state)
• Idempotent: No (multiple creates = multiple resources)
• Cached: No
• Bookmarkable: No

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name": "Bob", "email": "bob@example.com"}

Response:

HTTP/1.1 201 Created
Location: /api/users/2
Content-Type: application/json

{"id": 2, "name": "Bob", "email": "bob@example.com"}

When to Use Each

Scenario	Method
Read a page	GET
Search with parameters	GET
Submit a form	POST
Upload a file	POST
Create a new resource	POST
Login (send credentials)	POST

PUT, PATCH, and DELETE are used for modifying resources.

PUT Request

• Purpose: Update entire resource (replace)
• Body: Complete updated resource
• Idempotent: Yes
• Use when: You have the full resource data

PUT /api/users/1 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name": "Alice Updated", "email": "alice.new@example.com", "age": 30}

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 1, "name": "Alice Updated", "email": "alice.new@example.com", "age": 30}

PATCH Request

• Purpose: Partial update (modify specific fields)
• Body: Only fields to update
• Idempotent: Usually (depends on implementation)
• Use when: You only have some fields to update

PATCH /api/users/1 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"email": "alice.updated@example.com"}

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 1, "name": "Alice", "email": "alice.updated@example.com"}

DELETE Request

• Purpose: Remove a resource
• Body: Usually empty
• Idempotent: Yes
• Safe: No

DELETE /api/users/1 HTTP/1.1
Host: api.example.com
Authorization: Bearer token123

Response:

HTTP/1.1 204 No Content

PUT vs PATCH

PUT (Replace entire resource):
{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "age": 25,
  "role": "admin"
}

PATCH (Update specific fields):
{
  "email": "newemail@example.com"
}

Understanding safe and idempotent properties helps design reliable APIs.

Safe Methods

A method is safe if it doesn't modify server state.

Method	Safe	Reason
GET	✅	Read-only
HEAD	✅	Like GET but no body
OPTIONS	✅	Returns allowed methods
TRACE	✅	Echoes request back
POST	❌	Creates resources
PUT	❌	Replaces resources
PATCH	❌	Modifies resources
DELETE	❌	Removes resources

Idempotent Methods

A method is idempotent if making the same request multiple times has the same effect as making it once.

Method	Idempotent	Why
GET	✅	Same request returns same data
HEAD	✅	Same as GET
OPTIONS	✅	Returns same allowed methods
PUT	✅	Replace = same result every time
DELETE	✅	Delete = gone, same result
PATCH	⚠️	Depends on implementation
POST	❌	Multiple creates = multiple resources

Practical Examples

// GET is safe and idempotent
GET /users/1  // Always returns user 1
GET /users/1  // Same result
GET /users/1  // Still same result

// PUT is idempotent but not safe
PUT /users/1 {name: "Alice"}  // Sets user 1 name
PUT /users/1 {name: "Alice"}  // Same result
PUT /users/1 {name: "Alice"}  // Still same result

// POST is neither safe nor idempotent
POST /users {name: "Alice"}   // Creates user 2
POST /users {name: "Alice"}   // Creates user 3
POST /users {name: "Alice"}   // Creates user 4

// DELETE is idempotent but not safe
DELETE /users/1  // Deletes user 1
DELETE /users/1  // User already deleted (204)
DELETE /users/1  // Still 204

Why This Matters

• Retries: Safe/idempotent methods can be safely retried
• Caching: Only safe methods should be cached
• Browser behavior: Back button uses cached GET responses
• Load balancers: Can retry idempotent requests on failure