Menu
Find my path
Software Testing

API testing beyond a 200 response: a practical checkout exercise

By SPOTHUB · · 4 min read

Prepared with AI assistance and linked primary sources. Examples are illustrative unless stated otherwise.

A `200 OK` proves that the server reports successful handling of that HTTP request; it does not prove that the returned data is correct, the intended business change occurred, unauthorized users are blocked, or invalid inputs fail safely. A useful API test checks status, headers, body contract, business rules, persisted state and negative cases.

What 200 OK actually tells you

This is an evergreen API-testing exercise, not a report about a new tool release. RFC 9110 defines a 200 response as meaning that the request succeeded. It also explains that the meaning of the response content depends on the request method: a GET returns a representation of the target resource, while a POST response represents the status of or result from the action.

That protocol signal is valuable, but it is deliberately general. An endpoint can return 200 with an empty list when the expected order is missing, with a JSON object that has the wrong field types, or with another customer’s data. The transport result can therefore be successful while the product behaviour is wrong.

Source: RFC 9110: HTTP Semantics

Check the contract as well as the status

Imagine a fictional `GET /orders/ORD-104` endpoint. Its documented success response should contain an order identifier, customer identifier, currency, total and status. After checking for 200, assert the response content type, required fields, data types and allowed status values. Then verify exact business facts, such as the requested identifier and the expected calculated total.

OpenAPI describes responses for an operation by status code and can associate response content with a schema. A schema check can catch a missing `currency` field or a numeric value returned as text. It cannot decide whether `1499` is the correct total for this order unless the test supplies an independent expectation. Contract and business assertions solve different problems, so use both.

Source: OpenAPI Initiative: Content of Message BodiesOpenAPI Specification 3.0.0

Verify the state change behind a successful response

For a fictional `POST /orders/ORD-104/pay`, do not stop after the response. Read the order again through an approved test interface and confirm that its state changed from `pending` to `paid` exactly once. Check that the payment reference is linked to the correct order and that unrelated orders remain unchanged.

Repeat the same request using the same idempotency key if the API supports one. The expected result belongs to the product contract: the service might return the original result, a conflict or another documented response. The important test is that a retry does not create an unintended second payment. Never run payment-style exercises against a live system or real account without explicit authorization.

Source: RFC 9110: HTTP Semantics

Authorization needs another identity

A response can have perfect JSON and still expose the wrong person’s resource. OWASP’s authorization-testing guidance models access using the feature and logical role, sometimes adding the data dimension. For this order example, test the same endpoint as the owning customer, a different customer and an unauthenticated caller in an isolated environment.

The second customer must not gain access merely by changing `ORD-104` in the path. Assert the documented denial response and confirm that its body does not leak order details. Avoid assuming that one `401` or `403` test covers every resource; authorization is connected to both the action and the specific object being requested.

Source: OWASP: Authorization Testing Automation Cheat SheetOWASP API Security Project

Complete the six-check API lab

Build a small local mock API or use a disposable training environment containing two fictional customers and three orders. Write one happy-path request and then expand it into a compact test matrix. Keep the expected values outside the API response so the test does not merely repeat whatever the server returned.

Record each request, the expected contract and the observed result. If the API documentation is unclear, mark the ambiguity rather than inventing a rule. A failing test can reveal a defect in the implementation, the test data or the documented contract; investigate which one before changing the assertion.

  • Protocol: assert the exact expected status and `Content-Type`, not only any 2xx response.
  • Contract: validate required fields, types and allowed values against the documented schema.
  • Business rule: independently calculate the expected order total and compare it.
  • State: retrieve the order after the action and verify the intended persisted change.
  • Authorization: repeat the request with a second identity and without authentication.
  • Failure behaviour: test an unknown ID, malformed input and a safe retry without corrupting data.

Source: OpenAPI Specification 3.0.0OWASP: Authorization Testing Automation Cheat Sheet

What to show in a testing portfolio

Keep the API contract, minimal test data, test matrix and a short failure investigation. Explain why each assertion exists and which risk it detects. A screenshot showing only a green 200 response is weak evidence because another person cannot see whether the returned order, permissions or state were correct.

Learners in Chennai or online can use this exercise while exploring SPOTHUB’s AI-Powered QA and SDET learning path. Use only systems you own or are authorized to test, remove secrets from reports and test data, and avoid presenting a small exercise as a production security audit. Training supports practice but does not guarantee employment or a particular outcome.

Sources and further reading

Spot an error? Email info@spothub.in with the article link and correction.

← All articles
Find My IT Career Path