An API does not communicate only through its response body. The HTTP status code is also part of its contract.
A successful request should not return the same status code as an authentication failure, invalid input, a missing resource, or an unsupported HTTP method. Clients, monitoring tools, and other services rely on these distinctions.
For example:
201 Created for a successfully created resource
400 Bad Request for invalid input
401 Unauthorized for missing or invalid authentication
403 Forbidden for insufficient permissions
404 Not Found for an unavailable resource
405 Method Not Allowed for an unsupported method
429 Too Many Requests when rate limits are exceeded
500 Internal Server Error only for unexpected server failures
Incorrect response codes can hide bugs, confuse API consumers, and expose information about protected resources.
Response code testing should cover both successful and unsuccessful scenarios. An API that returns the wrong status code is not behaving correctly, even if the response body looks reasonable.
Rentgen helps explore these cases automatically from a working cURL request, including invalid input, authentication failures, unsupported methods, and unexpected responses.
HTTP status codes are not decoration. They are functionality.
Full white paper:
https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html
Top comments (0)