In this post, we will discuss an extremely important part of API testing: status codes. Imagine that you open the search engine and type any word or phrase to look for, then you tap "search," and in that moment you basically send the request to a certain server. After this, if the request was successful, you will get the information you’ve searched for, and if it was not, you will have problems loading the page (probably a «Page not found» alert will appear). Sometimes on the screen, in cases of failed response from the server, you can see the three-digit code – that's the status code. Basically, these three numbers show the success of your connection or its failure and indicate the exact mistake that appeared.
The same happens when you test APIs: in each response, you will see the status code, which will indicate the correctness of the received response. There are 5 main categories of HTTP response status codes:
Informational responses – 1**
This type of status code indicates that the request was received and understood and alerts the client to wait for a final response. The most commonly used are:
100: Continue – an interim response, if the request has already been completed, the client should continue the request or ignore the response.
101: Switching protocols – indicates that the user must modify the request header to one that the server requires.
102: Processing – there is currently no response available.
Successful responses – 2**
Successful status codes indicate that the request performed as intended, depending on the request method (GET, POST, PUT, etc.). Successful status codes include:
200: Ok – the request was successful.
201: Created – the attempt to create some element on a concrete server was successful.
202: Accepted – means that although the request has been accepted for processing, that processing has not yet been finished.
203: Non-Authoritative information – the provided data is gathered from a local or external copy rather than being an exact match to what is available from the origin server.
204: No content – although the request was received, the client did not get any data.
How successful response code looks like in API Tester app
Redirection messages – 3**
This status code group is used to show the user that the information he or she is looking for is no longer kept on the provided server or address. Here are the most common indicators:
300: Multiple choices – more than one alternative for the response is available.
301: Moved permanently – the old response URL is no longer available; the new one will be shown in the response.
302: Found – the intended resource momentarily resides under another URL.
303: See other – redirects the user to a different URL.
304: Not modified – if the resource hasn't changed since the last document cache, the client will be able to request it.
Client error responses – 4**
The major status codes show that the error with sending the request happened on the client side. This is probably one of the most important status code groups because it helps users understand why it is impossible (at the moment) to receive the desired response. Among them are:
400: Bad request – the server may not be able to fulfill the request due to something that is perceived to be a client error.
401: Unauthorized – no valid authentication information provided by the user.
403: Forbidden – the data is not accessible to the client.
404: Not found – the server cannot return any information because the resource or URL is no longer available.
405: Method not allowed – the user can’t use the chosen method (GET, DELETE, POST etc.) to perform an action.
408: Request timeout – the server did not receive the entire request message in the time it was willing to wait.
410: Gone – when the requested content has been permanently removed from the server, this response is provided without a forwarding address.
411: Length required – no valid Content-Length Header provided to the server (in cases when this is obligatory to receive a response).
412: Precondition failed – the wrong request Headers provided by user.
415: Unsupported media type – the server does not support the requested data's required media format.
429: Too many requests – the API rate limits have been exceeded.
Server error responses – 5**
The last group of status codes represents that the server is unable to perform the correct work, and as a result, an error in API calls occurs. The main server error responses are:
500: Internal server error – indicates that the request couldn't be fulfilled because the server ran into an unforeseen problem.
501: Not implemented – the server is incapable to fulfill the request due to the lack of required functionality.
502: Bad gateway – shows that the server received an incorrect response while acting as a gateway to handle the request.
503: Service unavailable – the server is currently unavailable to form a response.
504: Gateway timeout – when the server is serving as a gateway and cannot get a response in time, an error response is returned.
505: HTTP version not supported – the major version of HTTP that was used in the request message is not supported by the server or is not supported at all.
511: Network authentication required – in order to access the network, the client must authenticate.
An error response status codes in API Tester app
Why is it important to know about HTTP status codes?
The theory described above is just a basic one that is obligatory for everyone who tests, develops, or explores different kinds of APIs for several reasons. To begin, if the user is unable to identify the cause of a failed response, the status code shows exactly where the error occurred, allowing the user to spend less time resolving the issue (when possible). Imagine there were no status codes: defining the origins of various issues would be much more difficult, wouldn't it? Second, when a request is successful and a response is received, status codes can provide useful information to the user, such as whether any content is available or whether the server has incorporated the request's changes. Finally, status codes are crucial for developers, as they are one of the main components of testing the correctness of apps or servers.
Thanks for reading! I hope you found this article helpful. Feel free to leave any questions, comments, or suggestions.
Btw, you can support my work by buying me a coffee! I'll leave here a few links for you:)
You can also support me on Coinbase
Top comments (6)
These are indeed very important indicators of server performance. Thank you for sharing.
You're welcome! 🤗I'm glad to have been able to provide some helpful information. If you have any other questions or need further assistance, please don't hesitate to ask.😊
Please write more such informative articles!
I will do my best to continue writing informative articles that are helpful to you and others. If you have any specific topics you would like to see covered in future articles, please don't hesitate to let me know. I'm always looking for new ideas and feedback on how to improve 😌
Your explanations were clear and easy to understand, I learned a lot from reading it. Thank you for taking the time to write such a useful article.
Thank you for your kind words!😍