HTTP Status Codes Explained: A QA-Friendly Guide

In this post, we’ll explore the different types of HTTP status codes, highlight the most common ones, and share best practices for using them correctly.

Before we dive in, if you just landed here, make sure to check the first article of this special REST API series: 👉 Understanding RESTful APIs: Why QA Engineers Should Care

What are HTTP Status Codes?

HTTP status codes are three-digit numbers included in the response of any API request. These codes tell the client what happened with their request, if it worked, failed, or needs something else to make it work.

These codes are part of the HTTP protocol, which defines how data is sent between clients and servers over the web. Understanding these codes is essential for anyone working with APIs, as they provide valuable insight to help identify issues and improve the user experience.

Think of them as standardized responses that help us (developers and testers) understand what’s going on behind the scenes so it can be easier to troubleshoot issues, identify errors, and fine-tune their applications’ performance.

What are the different types of HTTP status codes?

HTTP status codes are grouped into five categories, based on the first digit of the code:

1xx informational responses

These codes mean the server received the request and is still processing it. They’re rarely used in everyday API testing, but still good to know. Some of these codes are:

• 100 Continue: this means the server received the initial part of the request and the client can continue sending the rest.
• 101 Switching Protocols: this code informs the client that the server is switching protocols (e.g., to WebSocket) during the connection.
• 102 Processing: this means the server is still working on the request (still being processed).

2xx success responses

These codes mean that the server successfully did what was asked because the request was received, understood, and processed without any inconvenients. Some of the most common 200 code responses are:

• 200 OK: this means everything worked, the request was successful, and the server returned the requested data.
• 201 Created: this code indicates a new resource was created successfully by the server.
• 204 No Content: this means the request was successful, but there’s no content (data) returned by the server.

3xx redirection responses

These codes indicate that the client needs to take further actions to fulfill the request (like going to a different URL). Some of these codes are:

• 301 Moved Permanently: it means the resource has permanently moved to a new URL.
• 303 See Other: this code means the resource is available at a different URL and the client needs to perform a GET request to that new location in order to retrieve the resource.

4xx client error responses

These codes indicate that something went wrong on the client side, such as a bad input, a mistyped URL, missing authentication, etc. The most common 4xx responses include:

• 400 Bad Request: it means the request was malformed or invalid.
• 401 Unauthorized: this code indicates the client is not authorized to access the requested resource.
• 403 Forbidden: this code indicates the client is authenticated but not authorized to access the requested resource.
• 404 Not Found: it means the requested resource doesn’t exist on the server.

5xx server error responses

These codes mean something went wrong on the server side while trying to process the request. The most common 5xx responses include:

• 500 Internal Server Error: this is a generic error, it happens when the server encounters an unexpected issue that prevented it from fulfilling the request.
• 502 Bad Gateway: this means the server (acting as a gateway or proxy) received an invalid response from another server.
• 503 Service Unavailable: this code is used when the server is temporarily unable to handle the request (due to overload or maintenance).

Most Common HTTP Status Codes

Here are the status codes you’ll encounter most often in API testing:

Status Code	Meaning	Description
200	OK	The request succeeded and the server returned data.
400	Bad Request	The request is malformed or has invalid arameters.
401	Unauthorized	Authentication is missing or invalid.
403	Forbidden	Access to the resource is denied.
404	Not Found	The requested resource doesn’t exist.
500	Internal Server Error	A generic error occurred on the server.

Best Practices for Working with HTTP Status Codes

Using the right HTTP status codes is a key part of good API design. Here are some best practices for developers and testers alike:

• Design the API thoughtfully
  First, identify the expected outcome of each request scenario to every API endpoint. They must then write logic for these scenarios, including the appropriate codes within each corresponding method.

• Use the correct status codes
  Be specific. Don’t return 400 for everything, use 404 when something isn’t found, or 403 when access is forbidden.

• Include helpful error messages
  When something goes wrong, the server should return a clear message in the response body explaining what happened. You can also use custom error codes for app-specific cases.

• Handle redirects properly
  When using 3xx codes, always include the new URL in the Location header. This is important for usability and SEO.

• Don’t expose sensitive info
  Error messages should never include stack traces, file paths, or sensitive internal details. Instead, provide general error messages without revealing the implementation details or API security vulnerabilities.

• Document your status codes
  Your API docs should clearly explain which status codes are used in each situation. Keep them updated as your API evolves.

• Test edge cases
  Make sure your API testing covers bad requests, authentication errors, server crashes, and anything else that might trigger a specific status code.

Final Thoughts

Understanding HTTP status codes is fundamental to debugging and testing web APIs. If you’re a QA or junior developer, becoming familiar with these codes will make you more effective when working with backend systems. By knowing how to interpret and apply them correctly, you can quickly identify problems, validate responses, and ensure your applications behave as expected.

Next Up

👉 Coming up next: We will talk about tips and best practices to document REST API Test Cases.

👈 Back: When to Use GET, POST, PUT, DELETE and PATCH in REST APIs