Module 1, API Fundamentals, from API Mastery for QA. This is the full lesson, exactly as it appears in the course.

HTTP methods and status codes are the foundation of REST API communication. As a QA engineer you need more than definitions: you need to know when each is used, what to test for, and what a given status code is really telling you. This lesson covers the methods (GET, POST, PUT, PATCH, DELETE) and the status code families (2xx, 3xx, 4xx, 5xx), with examples and testing strategies for each.

The five HTTP methods

HTTP methods, also called verbs, tell the server what action to perform on a resource. Two properties matter throughout: a method is safe if it does not change server state, and idempotent if repeating the same request has the same effect as sending it once.

GET retrieves data. Safe, idempotent, cacheable, parameters go in the URL query string. It must never modify anything.
POST creates a new resource. Not safe, not idempotent (two POSTs create two resources), data goes in the request body, and it usually returns the created resource.
PUT replaces an entire resource. Not safe, but idempotent. It requires the full resource, and may create the resource if it does not exist.
PATCH partially updates a resource. Not safe, idempotency depends on implementation, and it sends only the fields that change. More efficient than PUT for small edits.
DELETE removes a resource. Not safe, but idempotent (deleting twice is safe). It may return the deleted object or just a success, and is sometimes a "soft delete" that only marks the record.

GET and POST: read and create

GET reads without side effects:

GET /api/users/123
GET /api/products?category=electronics&page=1
GET /api/orders/456/items

When you test GET, verify the right data comes back, check the JSON structure, try valid and invalid IDs, exercise filtering, sorting, and pagination, confirm caching headers, and make sure nothing is modified.

POST creates:

POST /api/users
Content-Type: application/json

{
  "name": "John Doe",
  "email": "john@example.com",
  "role": "admin"
}

When you test POST, verify the resource is created, confirm the response includes a new ID, send missing required fields and invalid data types, confirm duplicate submissions create separate resources, check the Location header points to the new resource, and verify field validation and error messages.

PUT, PATCH, and DELETE: replace, update, remove

PUT replaces the whole resource, so you send every field:

PUT /api/users/123
Content-Type: application/json

{
  "id": 123,
  "name": "John Smith",
  "email": "john.smith@example.com",
  "role": "user",
  "status": "active"
}

Test that the entire resource is replaced, that fields you omit are removed or reset to defaults, that non-existent IDs behave correctly, and that sending the same request twice is idempotent.

PATCH updates only what you send:

PATCH /api/users/123
Content-Type: application/json

{
  "email": "newemail@example.com"
}

Test that only the specified fields change, that everything else stays put, and that null values behave differently from missing fields. An empty body and invalid field names are good edge cases.

DELETE removes:

DELETE /api/users/123
DELETE /api/orders/456/items/789

Test that the resource is actually gone, that deleting a non-existent one is handled, whether it is soft or hard delete, how cascades and dependencies behave, and that authorization is enforced so a user cannot delete what they should not.

Status code families

Status codes report the result of a request and fall into five groups.

1xx Informational: the request was received and processing continues. You will rarely assert on these in API tests.
2xx Success: the request worked.
3xx Redirection: the client needs to take another step.
4xx Client error: your request was wrong.
5xx Server error: the server broke, and these always need investigating.

A quick rule to remember the split: 4xx errors are your fault, 5xx errors are server bugs.

2xx and 3xx in practice

The success codes you will see most:

200 OK: standard success, common on GET, PUT, PATCH, DELETE, returns the requested or updated resource.
201 Created: a resource was created (used with POST), and should include a Location header with the new URL.
202 Accepted: accepted but not yet processed, used for async work, should offer a way to check status later.
204 No Content: success with no body, common on DELETE or updates that return nothing.

A testing tip: always verify the response body matches the status code. A 200 with empty data can hide a real problem.

The redirection codes:

301 Moved Permanently: the resource has a new permanent URL.
302 Found: the resource is temporarily at a different URL, keep using the original.
304 Not Modified: nothing changed since last time (used with caching headers like If-Modified-Since), no body, saving bandwidth.

Test redirects both by following them to confirm the final destination works and by not following them to confirm the redirect itself is correct.

4xx and 5xx: errors you must test on purpose

Client errors (4xx) mean the request was wrong:

400 Bad Request: malformed JSON, missing fields, bad format.
401 Unauthorized: authentication missing, invalid, or expired.
403 Forbidden: authenticated but not allowed.
404 Not Found: the resource or endpoint does not exist.
405 Method Not Allowed: that method is not supported here.
409 Conflict: clashes with current state, like a duplicate or version mismatch.
422 Unprocessable Content (formerly Unprocessable Entity): valid syntax but failed business rules or validation.
429 Too Many Requests: rate limit hit, should include a Retry-After header.

For 4xx, deliberately trigger each condition, confirm the error messages are helpful, keep the error format consistent, and make sure nothing sensitive leaks.

Server errors (5xx) mean the server failed:

500 Internal Server Error: an unhandled exception, usually a server bug.
502 Bad Gateway: a gateway got an invalid upstream response, common in microservices.
503 Service Unavailable: temporarily down for maintenance or overload, should include Retry-After.
504 Gateway Timeout: an upstream service was too slow.

For 5xx, log and report immediately, check whether the error is consistent or intermittent, confirm no sensitive data leaks, and test that retry logic works.

Putting it together: common scenarios

A few canonical cases worth keeping in your test suite:

POST /api/users            -> 201 Created, body has new user + ID, Location header set
GET  /api/users/999999     -> 404 Not Found, body explains user not found
PUT  /api/users/123        -> 401 Unauthorized when no auth token is sent
DELETE /api/users/123      -> 403 Forbidden when a non-admin tries to delete

Build the happy path first, then layer the error cases on top. And always assert on the response body in addition to the status code: a correct number with the wrong payload is still a bug.

The rule of thumb

GET retrieves, POST creates, PUT replaces, PATCH updates, DELETE removes. Status codes group into 2xx success, 3xx redirect, 4xx your fault, 5xx server bug. For every endpoint, test both the success case and the failure case, and assert on the body as well as the code.

HTTP methods and status codes