Encountering an “unspecified” error during development is like hitting a snag with no clue how to fix it. These errors are cryptic messages that leave developers and users scratching their heads. So, when building an application, it is important to clear the error messages using the correct Rest API response codes.
This blog post explores the importance of specifying errors and how standard HTTP status codes can simplify troubleshooting for everyone. Read on to learn why clarity in error reporting is essential and how it impacts user experience.
Table of Contents
What are HTTP Status Codes?
HTTP status codes are standard response codes given by web server applications to indicate the outcome of a client’s request. They are part of the HTTP response protocol and are essential for web development and API interaction. These codes help identify a request’s status, whether it is a success, has errors, or requires further action.
What are Rest API Response Codes?
Simply put, REST API response codes are specific HTTP status codes used in the context of REST (Representational State Transfer) APIs. They inform the client about the result of the API request, enabling the client application to respond appropriately. These codes follow the same standard HTTP protocol and ensure consistency across different web services and APIs.
Clasification of HTTPS Status Codes
The HTTPS status codes are systematically grouped into five distinct categories, each represented by the first digit of the code. These categories include 1xx, 2xx, 3xx, 4xx, and 5xx. This classification ensures a standard method for handling HTTP requests and responses across different platforms and applications. Let’s have a quick look at all of them:
1xx (100 Series Responses): ” Starting the Reuest”
The 1xx status codes are like a heads-up from the server. These API status codes indicate that the server has received and is working on your request. The 100 status code is like a message: I’ve got your request and am currently processing it. This HTTP response happens directly with your browser; you typically won’t see any indication on screen.
2xx (200 Series Responses): “Mission Successful”
Encountering a 2xx status code means your request hit the mark. The server has successfully processed the browser’s request, and the page or resource is ready to view. The 200 status code, often seen as “OK,” signifies that everything worked as expected. You can see the results of these REST API response codes directly in your browser.
3xx (300 Series Responses): “Redirection”
3xx codes are redirection messages, and the server’s way of saying: What you’re looking for isn’t here, but I’ll guide you to the right place. For instance, if a page has moved, the server uses these codes to direct the browser to the new location. This way, you can find what you’re seeking without any hassle.
4xx (400 Series Responses): “Oops, There’s a Hitch”
The 4xx series signals that something went wrong with the request. This isn’t about the server; it’s about the user’s request. It could be due to a typo in the URL, a page no longer exists, or other user errors. These codes are the server’s way of saying, “Check your end; the issue lies there.”
5xx (500 Series Responses): “Trouble on Server’s Side”
5xx status codes are the server’s SOS signals, indicating that something went wrong on its end. Whether it’s a temporary glitch or a more serious issue, these codes alert you that the server cannot fulfill your requests because of a problem with the server. It’s an admission from the server that it’s currently unable to process your request as expected.
A Complete List of HTTP Status Codes
Here is the list of the most common HTTP response codes and their explanation and use:
1xx HTTP Status Code Series: Informational Responses
| STATUS CODE | EXPLANATION |
| HTTP 100 (Continue) | It is the response that the request sent to the server by the user (client) is processed properly. Furthermore, it indicates that there is no problem with the request using the HTTP status code. |
| HTTP 101 (Switching Protocols) | If the client asks the server to change the protocol, the response from the server is sent with HTTP 101. |
| HTTP 102 (Processing) | The HTTP 102 status code is the server’s response indicating that the request is being processed. The main purpose of sending this response is to prevent time out of the request. |
| HTTP 103 (Early Hints) | The HTTP 103 status code returns some response headers before the server responds. It is the response to the request sent by the client to the server. |
2xx HTTP Status Code Series: Success Responses
| STATUS CODE | EXPLANATION |
| HTTP 200 (OK) | HTTP 200 indicates that the client’s request to the server has been answered successfully. Depending on the nature of the request, the server includes optional data in its response. |
| HTTP 201 (Created) | The HTTP 201 status code is used when the server successfully responds to the client’s request. Furthermore, it creates a suitable new resource for the request. |
| HTTP 202 (Accepted) | It is used when the server accepts the client’s request to the server. However, the request is still under process on the server side. It is not certain whether the client’s request will complete after the response with the HTTP 202. In some cases, the request may fail. |
| HTTP 203 (Non-Authoritative Information) | The HTTP 203 status code is sent when the server successfully answers the client’s request. In this case, the metadata sent from the server changes when it reaches the client. |
| HTTP 204 (No Content) | The HTTP 204 status code is used when the client’s request is successful, but there is no content. The user should send a request for old or different content. |
| HTTP 205 (Reset Content) | The HTTP 205 status code is sent when the client’s request is answered successfully and the request changes the document’s image (e.g., resetting the document). For example, when the user presses the reset button on an HTML document, they get HTTP 205 status code response. |
| HTTP 206 (Partial Content) | If the client (browser) uses range headers in the header section, the HTTP 206 status code will appear. When the server uses this header, the client can pause and continue the document from the server. For example, you can stop and start the download file from the server you are making a request to. |
| HTTP 207 (Multi-Status) | The HTTP 207 status code is the response when an XML Document containing more than one HTTP status code comes in the server’s response to the client’s request. |
3xx HTTP Status Code Series: Redirection Responses
| STATUS CODE | EXPLANATION |
| HTTP 300 (Multiple Choices) | When the server receives a request from a client and has many possible responses, it sends back an HTTP 300 status code. This basically means that there are multiple options for the same request. The user needs to pick one of these options. If the server prefers an option, it will point to it in the location header section. |
| HTTP 301 (Permanent Redirect) | The HTTP 301 status code is sent by the server as a response when the client moves the web page completely. If the request is or Head, the user (client) directly sees the new URL address. |
| HTTP 302 (Temporary Redirect) | When the server temporarily moves a web page to a new URL, it sends an HTTP 302 status code. Furthermore, this code tells the client to use the original URL to access the desired resource. Unlike a 301 redirect, search engines don’t see this type of redirect as permanent, so PageRank doesn’t carry over. |
| HTTP 303 (See Others) | If a client’s request to a server is not complete using the URL, the server sends an HTTP 303 code. These Rest API response codes suggest the client try a different method, like requesting a different URL. If the resource isn’t unavailable via GET, the server uses HTTP 303 to direct the client. |
| HTTP 304 (Not Modified) | If a client sends a request for a web page or document that hasn’t changed since their last visit, the server responds with an HTTP 304 code. This code aims to prompt the client to use cached versions of the content to speed up loading times, essentially telling the client, “No updates here; use what you already have.” |
| HTTP 305 (Use Proxy) | If the client’s web page requests are viewable only with the proxy (different location header), the server returns the HTTP 305 status code as a response. |
| HTTP 307 ( Temporary Redirect) | If the client sends a request from a different URL address, the response is an HTTP 307 status code. As with the HTTP 302 status code, the server sends the message to the client. It indicates that users should continue to use this URL to reach the requested resource. The main difference between 302 redirect and 307 is the form of the request. |
| HTTP 308 (Permanent Redirect) | The server returns the HTTP 308 status code as a response to notify that the request sent from the client to the server as an alternative to HTTP 301 has been successfully moved to a different URL. Unlike HTTP 301 redirect, the HTTP request method cannot change in HTTP 308 redirect. |
4xx HTTP Status Code Series: Client Error Responses
| STATUS CODE | EXPLANATION |
| HTTP 400 (Bad Request) | The server sends the HTTP 400 status code when it cannot answer the client’s request due to an incorrect request (syntax error). |
| HTTP 401 (Unauthorized) | The server returns the HTTP 401 status code to inform the client that the client cannot perform the operation on the web page without authorization. |
| HTTP 402 (Payment Required) | The server reports to the user that payment is required to view the web page by returning the HTTP 402 status code. Typically, you might encounter HTTP 402 error codes on pages with usage limitations to specific quotas. |
| HTTP 403 (Forbidden) | When the server can fulfill the client’s request but the client isn’t authorized to access the resource, it responds with the HTTP 403 status code. The client should not repeat the unauthorized request. |
| HTTP 404 (Not Found) | When the server cannot find resources related to the web page requested by the client, it returns an HTTP 404 status code in response. This is the most common mistake on the web. |
| HTTP 405 (Method Not Allowed) | The HTTP 405 status code indicates that the HTTP request method (GET or POST) sent by the client is not accessible. Typically, this occurs when the server recognizes the request method, but the resource does not allow it. Similarly, this error code arises when using request methods unrecognized by the server, such as WebDAV. |
| HTTP 406 (Not Acceptable) | The server returns the HTTP 406 status code as a response when it cannot serve the client’s request in a certain format. For example, if the client requests an image in GIF format while only a PNG version is available on the server, the server responds with HTTP 406. |
| HTTP 407 (Proxy Authentication Required) | Similar to the HTTP 401 request, the server prompts the client for authentication when encountering HTTP 407 status code. If a proxy is there, the server also seeks authorization from the proxy. Furthermore, it asks the client to authenticate the proxy before establishing a connection. |
| HTTP 408 (Request Timed Out) | If the server cannot complete the request of the client within the specified time, it returns with the HTTP 408 Rest API response codes. |
| HTTP 409 (Conflict) | In cases where processing the client’s request would cause confusion about the requested resource, the server returns the HTTP 409 status code in response. |
| HTTP 410 (Gone) | The server returns the HTTP 410 status code in response when it permanently deletes a requested resource and ensures it won’t be available again. This status code specifically informs search engines that the content is permanently out of the server. |
| HTTP 411 (Length Header Required) | If the server cannot process the client’s request because it does not contain a content-length header, it responds with an HTTP 411 status code. |
| HTTP 412 (Precondition Failed) | The HTTP 412 Rest API Response Codes are the response of a condition communicated to the server. This condition is known as “the client cannot be met.” |
| HTTP 413 (Request Entity Too Large) | If the client sends a file request to the server that is too large, the server rejects the operation and responds with the HTTP 413 status code. |
| HTTP 414 (Requested URL Too Large) | When the URL the client requests is too large (long), the server sends the HTTP 414 status code as a response. URL length is not definite due to HTTP standards; however, server configuration settings limit it. |
| HTTP 415 (Unsupported Media Type) | In cases where the server does not support the media type of the file that the client needs, the HTTP 415 status code is the response. |
| HTTP 416 (Requested range not satisfiable) | If part of the resource the client requests is invalid or unavailable, the server returns the HTTP 416 status code in response. Such situations often appear with partial (progressive) downloads. |
| HTTP 417 (Expectation Failed) | If the server does not meet the conditions in the expect header field in the client’s request header, it returns the HTTP 417 status code in response. |
| HTTP 421 (Misdirected Request) | When the client forwards a request to a server that is unable to send a response, the server returns the HTTP 421 status code. |
| HTTP 422 (Unprocessable Entity) | If the request sent by the client to the server contains semantic errors, the server cannot process the request and returns HTTP 422 status code in response. |
| HTTP 423 (Locked) | The information that the resource requested by the client is currently a locked resource is reported by the server with the HTTP 423 status code. |
| HTTP 424 (Failed Dependency) | The server returns the HTTP 424 status code when the resource requested by the client cannot be processed because the previous resource related to the relevant resource could not be processed. |
| HTTP 425 (Too Early) | The HTTP 425 status code is sent as a response when a request to the server is in a replayable state, and the server does not want to process it. |
| HTTP 426 (Upgrade Required) | In case the requesting client needs to upgrade to Transport Layer Security (TLS / 1.0), the HTTP 426 status code is returned in response. |
| HTTP 428 (Precondition Required) | The server responds with an HTTP 428 status code when it requires specific conditions beforehand to process the client’s request sent to the server. |
| HTTP 429 (Too Many Requests) | When the client sends a large number of requests to the server in a limited time, the server returns the HTTP 429 status code in response. |
| HTTP 451 (Unavailable For Legal Reasons) | When the server detects that the client is trying to access a legally blocked resource in a region or country, it responds with the HTTP 451 status code. This blocking can be due to copyright issues, legal bans (blackouts), or national restrictions. |
5xx HTTP Status Code Series: Server Error Responses
| STATUS CODE | EXPLANATION |
| HTTP 500 (Internal Server Error) | When the server is unable to process the client’s request due to an identified internal error, it returns the HTTP 500 status code in response. The server may be unable to process the request because of program errors on the server or database errors. |
| HTTP 501 (Not Implemented) | The server returns the HTTP 501 status code when it cannot handle a request from the client due to lack of functionality. Typically, the web host causes this problem and resolves it. |
| HTTP 502 (Bad Gateway) | In cases where a client uses a proxy, an HTTP 502 status code shows to the client in response when one of the servers providing the data streams returns incomprehensible Rest API response codes to the other. |
| HTTP 503 (Service Unavailable) | When unavailable, the server sends an HTTP 503 response to the client. Therefore, it often occurs on websites experiencing high traffic, during data transfers, or when it is undergoing maintenance. Even small or medium sites may encounter this issue if their server can’t handle the incoming traffic. |
| HTTP 504 (Gateway Time-out) | If you’re using a proxy connection, and the proxy server takes too long to handle your request, you’ll receive an HTTP 504 status code as a response. |
| HTTP 505 (HTTP Version Not Supported) | When the HTTP version doesn’t support the client’s request, an HTTP 505 status code come in response. |
| HTTP 507 (Insufficient Storage) | When the server has insufficient storage space and cannot complete client requests, it responds with an HTTP 507 status code. |
| HTTP 509 (Bandwidth Limit Exceeded) | When a client-to-server request is rejected because it would fill the server’s traffic bandwidth if processed, the server returns the HTTP 509 status code in response. |
| HTTP 511 (Network Authentication Required) | The HTTP 511 status code is the response when the client must first authenticate before establishing a network connection. |
| HTTP 521 (Web Server is Down) | The HTTP 521 error is a status code for websites using Cloudflare. It appears when the client (browser) successfully connects to Cloudflare, but Cloudflare can’t connect to the website’s server. Cloudflare indicates that the server hosting the webpage isn’t responding in this situation. |
How to Address Specific Rest API Response Codes?
1) Ensuring Continuity in 2xx Success Codes
While 2xx codes signal success, they still require attention to ensure the intended outcomes:
- 200 OK: Verify that the response body contains the necessary resources. Inconsistent data might indicate backend logic errors.
- 201 Created: Ensure the new resource is accessible at the provided URI. Implement proper URI design and database integrity checks to prevent inconsistencies.
- 204 No Content: When used in DELETE operations, confirm you delete the resource and that dependent resources are not adversely affected.
2) Managing Flow 3xx Redirections
Redirection codes can affect user experience and SEO. So, it is important to take these issues seriously.
- 301 Moved Permanently: Use this code cautiously, as it can impact SEO. Verify that all references to the old URL are up to date.
- 302 Found: The 302 code’s behavior can be ambiguous. So, opt 303 or 307 to indicate explicitly the nature of the redirection for POST requests.
- 304 Not Modified: Implement ETag or Last-Modified headers correctly to utilize this status efficiently, reducing bandwidth and improving load times.
3) Informing and Guiding Users about 4xx Client Errors
Client error responses are crucial for guiding users or developers interacting with your API:
- 400 Bad Request: Include a response body that details what part of the request is incorrect. This is invaluable for debugging.
- 401 Unauthorized vs. 403 Forbidden: Clearly differentiate between authentication (401) and authorization (403) issues in your Rest API response codes.
- 404 Not Found: Provide suggestions or resources in the response body to help clients correct their requests.
- 429 Too Many Requests: Implement rate limiting thoughtfully and inform clients about their limits via headers (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After).
4) Preventing 5xx Server Errors
Server errors should prompt immediate diagnostic and corrective actions:
- 500 Internal Server Error: Implement detailed error logging on the server to quickly identify the cause. Avoid exposing sensitive information in the response.
- 503 Service Unavailable: Use this code for maintenance windows or unexpected downtime, and communicate expected durations to clients if possible.
Diagnostic Tools and Techniques for Rest API Response Codes
- Browser Developer Tools: Modern browsers include developer tools for inspecting HTTP requests and responses, including status codes, headers, and payloads.
- cURL and Postman: Command-line tools cURL and Postman are good for testing and debugging HTTP requests and Rest API Response Codes.
- Logging and Monitoring: Implementing comprehensive logging on the server side and utilizing monitoring tools can preemptively diagnose these issues.
Best Practices for Diagnostics and Rest API Response Codes Resolution
- Automated Testing – You can use automated tests to simulate various API requests and responses. It includes error scenarios to ensure your application handles them gracefully.
- Comprehensive Logging – Log requests, responses, and significant processing steps in your server-side code to aid in diagnosing issues.
- Client Error Handling – Design your client applications to appropriately handle different HTTP status codes. These Rest API Response Codes must provide users with clear messages and actions to take in case of errors.
- Monitoring and Alerts – Utilize monitoring tools to track API health and performance. This way, you can set up alerts for unusual patterns or error rates.
Why Choose RESTful API from APILayer?
APILayer offers a suite of powerful, scalable, and easy-to-integrate REST APIs across various categories designed for developers by developers. With robust documentation and extensive support for Rest API response codes, APILayer streamlines development workflows and enables rapid feature deployment. You can also get a free demo and try it yourself before purchasing.
Wrapping it Up!
Mastering HTTP status codes is not just about memorization. It requires an understanding of the implications of each Rest API Response codes and the knowledge to address the issues. Developers can enhance their REST APIs’ reliability and user experience by employing the right tools and learning error handling. Therefore, Improve your knowledge base to anticipate and mitigate API status code issues before they impact user experience.
FAQs
Q. What is the difference between 401 and 403 Rest API response codes?
A 401 is a Unauthorized response code. This indicates that the request was not applicable because it lacks valid authentication credentials for the target resource. Conversely, a 403 Forbidden response code means the server understood the request but refused to authorize it. It often happens due to a lack of permission to access the resource.
Q. Why might a server return a 500 Internal Server Error?
A server might return a 500 Internal Server Error when it encounters an unexpected condition. This condition might prevent it from fulfilling the request. Furthermore, it is a generic error message when no specific message is suitable.
Q. How should I handle a 429 Too Many Requests response code?
A 429 Too Many Requests response code indicates the client has sent too many requests in a given time. You should handle this by implementing rate-limiting procedures, possibly utilizing a “retry-after” time if provided by the server.
Q. Can a REST API return a custom response code?
While REST APIs typically use standard HTTP response codes, returning custom response codes is possible. We don’t recommend this practice as it can lead to confusion and interoperability issues with standard HTTP clients and tools. Also, you cannot return a custom HTTP response code if it is a Mobile (JSDO) REST application.
Q. How can I find more information about specific Rest API response codes?
You can find more information about specific response codes in the HTTP/1.1 specification documentation or by consulting the API documentation. You can gather info for the specific service, as some APIs provide additional context for certain response codes.
