Get familiar with these http response status codes

What are HTTP status codes?

HTTP status codes are response codes that are returned by web servers along with responses indicating whether a request sent by the client was processed successfully or not. They are part of the HTTP headers and hence are mostly not visible to the users except when they inspect request response from the browser developer's tools network tab.

There are five classes of HTTP status codes available, and we will take a look at some of the most prevalent in each of them.

Information responses (1xx)

This class of response codes returned by the server does not indicate any form of problem. They communicate that the request was received and understood by the server, and in most cases, the client should wait while it processes the sent request.

100 Continue

This response code indicates that the server has not rejected the client's request header or request and that the request body should be sent for processing or ignore the response if the request body was complete.

Use case: A good example is when a client wants to send large content to the server, it will, first of all, send an Expect: 100 - continue in the request header to the server. When the server returns a response with a 100 Continue status code, it will now proceed with sending the request body.

102 Processing

This status code informs the client that the server has received the request and is currently processing it, but has not yet completed it.

Successful responses (2xx)

This class of status codes indicates the action requested by the client was received, understood, accepted, and processed successfully.

200 Ok

The server returns this status code when the client's request is successful. The server also sends along with the code the requested content in the response body and the content type.

Use case: GET and PUT requests that require content in the response body should return status code 200 even if the content is an empty array. If the response has no body, then the 204 No Content response body should be used instead.

201 Created

When the server returns status code 201 to the client, it means that the request sent by the client to the server has succeeded, creating one or more resources as a result. 201 Created response code always contains the newly created resource in the request body.

Use case:

• POST or PUT request after creating a new resource.
• The origin server must create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server should respond with a 202 Accepted status code response instead.
• The response may or may not contain the response body.

202 ACCEPTED

This status code indicates that the server has received the request but has not yet acted upon it, and the client should not expect any further response concerning it since HTTP has no standard way to communicate back the outcome of the request.

Use case: It is intended for cases where another process or server handles the request, or for batch processing. In this case, the entity returned with this response should include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

204 No Content This response code means that the server, having completed the request, does not need to return a response body.

Use case: Request where there is no need to return contents in the response body.

Redirection (3xx)

Redirection is the process used to communicate that a resource is no more available in the requested location. There are several HTTP status codes available for redirections, to provide visitors with information about where to find the content they requested.

301 Moved permanently

This tells the client that the requested resource has been moved permanently, and then provides the URL to the new location of the resource.

302 Found

This status code informs the client that the resource they tried to access is temporarily hosted somewhere else. Because the change is temporary, the client shouldn’t update its links to the new location but keep hitting the endpoint that sent the 302 in case something changed.

Client error responses

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes apply to any request method. User agents should display any included entity to the user.

At the 400 level, HTTP status codes start to become problematic. These are error codes specifying that there’s a fault with your browser and/or request.

400 Bad request

The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, request size too large, invalid request message framing, or deceptive request routing). The client SHOULD NOT repeat the request without modifications.

401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that the included credentials are invalid.

403 Forbidden

The server understood the request but is refusing to fulfill it and authorization will not help, so there is no need to repeat the request. If the request method was not HEAD and the server wishes to make public why it did not process the request, it SHOULD describe the reason for the refusal in the returned response. If the server does not want to make this information available to the client, it is proper to use the status code 404 (Not Found) instead.

404 Not found

The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.

In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 to hide the existence of a resource from an unauthorized client. This response code is probably the most famous one due to its frequent occurrence on the web

405 Method not allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. For example, using GET on a form that requires data to be sent via POST or using PUT on a read-only resource.

The response MUST include an Allow header containing a list of valid methods for the requested resource.

413 Request entity/payload too large

The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary the client may try again at a specified time.

415 Unsupported media type

The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.

429 Too many requests

The 429 status code indicates that the user has sent too many requests in a given amount of time (rate-limiting). The response representations SHOULD include details explaining the condition and MAY include a Retry-After header indicating how long to wait before making a new request. When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources. Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.

5XX Server error responses

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes apply to all request methods.

500 Server error

This status code indicates that there was an error on the server could not complete the request. This is a generic code that simply means that there an internal server error and it doesn't know how to handle it.

This code is typically generated by third-party plugins or even the connection to the database breaking.

502 Bad gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

503 Service unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.

504 Gateway timeout

The server, acting as a gateway, timed out waiting for another server to respond.” This is the code returned when there are two servers involved in processing a request, and the first server times out waiting for the second server to respond.