HTTP Methods, Status Codes, and Headers

HTTP Methods #

HTTP methods (also called verbs) define the action to be performed on a resource. Understanding them deeply is fundamental to API testing because using the wrong method or testing the wrong behavior is one of the most common mistakes.

GET — Retrieve Data #

GET requests retrieve data without modifying anything on the server. They are both safe (no side effects) and idempotent (same result regardless of how many times called).

GET /api/users HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>

Testing checklist for GET:

• Returns 200 OK with data for existing resources
• Returns 404 Not Found for non-existent resources
• Never modifies server state (verify database unchanged after GET)
• Supports filtering via query parameters
• Returns proper pagination for list endpoints
• Response format matches Accept header

POST — Create New Resources #

POST sends data to the server to create a new resource. It is neither safe nor idempotent — calling it multiple times may create multiple resources.

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "developer"
}

Testing checklist for POST:

• Returns 201 Created with the new resource (including generated ID)
• Returns Location header pointing to the new resource
• Validates required fields (returns 400 for missing data)
• Rejects duplicate entries appropriately (409 Conflict)
• Handles invalid data types gracefully

PUT — Replace Entire Resource #

PUT replaces the entire resource with the provided data. It is idempotent — sending the same PUT request multiple times produces the same result.

PUT /api/users/42 HTTP/1.1
Content-Type: application/json

{
  "name": "Alice Smith",
  "email": "alice.smith@example.com",
  "role": "senior-developer"
}

Testing checklist for PUT:

• Replaces all fields (fields not included should be removed or set to defaults)
• Returns 200 OK with updated resource or 204 No Content
• Creates the resource if it doesn’t exist (some APIs return 201)
• Is idempotent — same request twice produces identical result

PATCH — Partial Update #

PATCH applies partial modifications to a resource. Only the fields included in the request are updated.

PATCH /api/users/42 HTTP/1.1
Content-Type: application/json

{
  "role": "senior-developer"
}

Testing checklist for PATCH:

• Only updates specified fields
• Unmentioned fields remain unchanged
• Returns 200 OK with the updated resource
• Handles invalid field names appropriately

DELETE — Remove a Resource #

DELETE removes the specified resource from the server. It is idempotent — deleting an already-deleted resource should not cause an error (though the status code may differ).

DELETE /api/users/42 HTTP/1.1
Authorization: Bearer <token>

Testing checklist for DELETE:

• Returns 204 No Content (or 200 OK with confirmation)
• Resource is no longer accessible after deletion (GET returns 404)
• Subsequent DELETE of same resource returns 404 or 204
• Cascade behavior is correct (related resources handled properly)

Less Common Methods #

HTTP Status Codes #

Status codes are three-digit numbers that communicate the result of an API request. They are organized into five classes.

1xx — Informational #

Rarely seen in API testing:

• 100 Continue — server received headers, client should send body
• 101 Switching Protocols — server is switching to WebSocket

2xx — Success #

3xx — Redirection #

4xx — Client Errors #

5xx — Server Errors #

HTTP Headers #

Headers carry metadata about the request or response. They are key-value pairs sent alongside the body.

Essential Request Headers #

Authorization — carries authentication credentials:

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0...
Authorization: Basic dXNlcjpwYXNzd29yZA==
Authorization: ApiKey sk-1234567890abcdef

Content-Type — describes the format of the request body:

Content-Type: application/json
Content-Type: application/x-www-form-urlencoded
Content-Type: multipart/form-data; boundary=----FormBoundary

Accept — tells the server what response format the client prefers:

Accept: application/json
Accept: application/xml
Accept: text/html, application/json;q=0.9

Essential Response Headers #

Content-Type — describes the response body format:

Content-Type: application/json; charset=utf-8

Cache-Control — caching directives:

Cache-Control: no-cache, no-store, must-revalidate
Cache-Control: public, max-age=3600

Rate Limit Headers (non-standard but widely used):

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1625097600

CORS Headers — Cross-Origin Resource Sharing:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type

Security Headers to Test #

Testing Strategies #

Status Code Verification Matrix #

Create a matrix for each endpoint mapping inputs to expected status codes:

Header Testing Checklist #

1. Send requests without required headers — expect 400 or 401
2. Send requests with invalid Content-Type — expect 415 Unsupported Media Type
3. Verify CORS headers allow expected origins
4. Check security headers are present in all responses
5. Verify rate limit headers are accurate and consistent
6. Test Accept header content negotiation

Hands-On Exercise #

Using JSONPlaceholder or any test API:

1. Method testing: Send GET, POST, PUT, PATCH, and DELETE to /posts/1. Document the status code and response for each.
2. Status code hunting: Find requests that trigger at least 5 different status codes (200, 201, 204, 404, and one more).
3. Header inspection: For a GET request to /posts, list all response headers and identify which ones relate to caching, content type, and security.
4. PUT vs PATCH: Update a post with PUT (sending all fields) and then with PATCH (sending one field). Compare the results.

Key Takeaways #

• HTTP methods define the action: GET (read), POST (create), PUT (replace), PATCH (update), DELETE (remove)
• Safe methods (GET, HEAD, OPTIONS) never modify server state; idempotent methods (GET, PUT, DELETE) produce the same result when called multiple times
• Status codes communicate results: 2xx success, 4xx client error, 5xx server error — each code has specific meaning
• Headers carry critical metadata: authentication, content format, caching, security, and rate limiting
• A systematic approach to testing — mapping endpoints to expected methods, status codes, and headers — ensures comprehensive coverage