HTTP Methods & Status Codes in API Testing (GET, POST, PUT, PATCH)

HTTP Methods & Status Codes in API Testing

Every API request combines a method (what you want to do) with a URL (which resource), and every response comes back with a status code (what happened). This guide covers the five methods you'll test daily with request/response examples, what "safe" and "idempotent" really mean, PUT vs PATCH, status code families, HTTP versions and HTTPS.

The Methods at a Glance ⭐

• Safe — doesn't change anything on the server.
• Idempotent — sending it once or ten times leaves the server in the same state. Deleting user 101 twice still leaves user 101 deleted (the second call may return 404, but the state is the same). Creating a user twice with POST creates two users.

Why testers care: idempotent requests are safe to retry after a timeout; for POST, test what happens on a double submit (a duplicate order is a classic bug).

GET — Retrieve Data

GET /users/101
Accept: application/json

200 OK
{ "id": 101, "name": "Asha", "email": "asha@example.com" }

Used to fetch users, products, order history or search results. Query parameters filter and page results:

GET /users?role=tester&page=2

Test: 200 with the right data, 404 for a missing ID, correct filtering and paging, and that nothing changed on the server.

POST — Create a Resource

POST /users
Content-Type: application/json

{ "name": "Ravi", "email": "ravi@example.com" }

201 Created
Location: /users/102
{ "id": 102, "name": "Ravi", "email": "ravi@example.com" }

Used to create users and orders, submit forms and upload data.

Test: 201 and the new ID, the record really exists (GET it or check the database), 400/422 for invalid input, 409 for duplicates, 401 without a token.

PUT — Replace a Resource

PUT /users/101
Content-Type: application/json

{ "name": "Asha K", "email": "asha.k@example.com", "phone": "9876543210", "city": "Pune" }

200 OK   (or 204 No Content)

The client sends the complete resource. Fields you leave out may be cleared or reset — that's the difference from PATCH, and a common source of bugs.

PATCH — Update Some Fields

PATCH /users/101
Content-Type: application/json

{ "email": "asha.new@example.com" }

200 OK   (or 204 No Content)

Only the fields sent are changed.

Test: the changed field is updated and every other field is untouched — GET the resource afterwards to prove it.

DELETE — Remove a Resource

DELETE /users/101

204 No Content

Test: 204 (or 200), a following GET returns 404, related data is handled correctly (no orphan records), and a user without permission gets 403.

PUT vs PATCH ⭐

Example: a user has name, email, phone and address. To change only the email, PUT must send all four fields; PATCH sends just the email.

Interview tip: "We used PUT for full profile updates, so every field stayed in sync, and PATCH for single-field changes like email or status — and after each PATCH we verified with a GET that the other fields were unchanged."

Can GET Create a Resource?

It shouldn't. GET is meant to be safe and idempotent: it only reads. Browsers, proxies and crawlers may repeat or cache GET requests, so a GET that changes data can create duplicates or fire unexpectedly.

Use POST to create and PUT/PATCH to update. If you find a GET endpoint that changes data, report it — it's a design defect.

Status Code Families

A 5xx for bad input is a bug in itself — the server should validate and return a 4xx. Always check the error body too: a clear, structured message with no stack traces or internal details.

Full list with examples and test code: HTTP Status Codes Cheat Sheet.

Interview tip: "For every scenario we asserted the exact status code — 201 for creation, 400 for invalid payloads, 401 without a token, 403 for the wrong role, 404 for missing records — along with the response body."

HTTP Versions

• HTTP/1.1 — the long-standing default, supported everywhere.
• HTTP/2 — multiplexing (many requests over one connection), header compression, lower latency.
• HTTP/3 — runs over QUIC (UDP), faster connection setup and better on unreliable networks.

Methods and status codes are the same in every version, so your tests don't change — performance and connection behaviour do.

HTTP vs HTTPS

A request like POST /login carries credentials, tokens and personal data, so it must use HTTPS.

Test: HTTP requests are rejected or redirected to HTTPS, certificates are valid, and credentials never appear in URLs or logs.

Design full test sets — positive, negative and edge cases for each method — in the API Testing Scenario Lab.

From Real Projects

I've worked with APIs at the level this page covers: CRUD operations, HTTP methods, JSON and XML formats, and extracting and validating values with JSON path. A good habit from that work: test the full create–read–update–delete cycle for a resource and check each response in detail. Testsigma supports web, mobile and API test automation, so understanding APIs was part of understanding the product I was testing. Test the error codes as carefully as the success codes.

📚 Official documentation: MDN: HTTP request methods · MDN: HTTP response status codes

FAQs

What are the common HTTP methods?

GET (read), POST (create), PUT (replace), PATCH (partial update) and DELETE (remove) — plus HEAD and OPTIONS.

What is the difference between PUT and PATCH?

PUT replaces the entire resource; PATCH updates only the fields sent. Both usually return 200 with the resource, or 204 with no body.

Which methods are idempotent?

GET, HEAD, OPTIONS, PUT and DELETE. POST is not; PATCH isn't guaranteed to be.

Can GET create a resource?

It shouldn't — GET must only read data. Creating data with GET is a design defect.

What do 2xx, 3xx, 4xx and 5xx mean?

Success, redirection, client errors and server errors.

Why should APIs use HTTPS?

To encrypt credentials, tokens and personal data in transit and prevent interception or tampering.

Related

• GET vs POST vs PUT vs PATCH
• API Testing in CI/CD: Newman, Jenkins & Debugging
• Postman API Chaining & Negative Testing
• Project & Scenario-Based API Questions