As part of the HTTP protocol HTTP Status Codes are returned to allow software to easily identify what the problem is and what they should do in response. For the most part, response status code should be really consistent and follow the HTTP 1.1 standard.
HTTP Response status codes are a three digit number. Web servers, whether they are front end or back end, return a 3 digit number (integer). The first digit defines the class of response and allow us to categorize whether it’s been successful or not.
The last two digits from the right get a lot more specific about what the browser or client should do with the results. HTTP status codes can be extended and nobody should ever be required to understand all of the error codes.
You need to know this because when you design an API or design a web application it’s really important to return consistent, expected and easily understandable error codes.
Categorizing The HTTP Status Code Responses off the First Number
Responses beginning with 1 are typically Informational responses. I haven’t ever seen these in the wild.
The original HTTP standard didn’t include any 100 response status codes, from what I can see nobody seems to use them.
Breaking Down Successful Responses
200 – the request is OK.
201 – the request is complete and a new resource is created
202 – the request is accepted for processing but not complete.
203 – I don’t remember ever seeing this before but its’ supposed to signify that a server that isn’t the original has responded.
204 – the request was fine, but there’s no body.
If your code is looking for successful responses, you can usually safely accept any request >= 200 and < 300.
When I build a REST API I typically only return 200, 201, and 204 http response codes. I find these generally cover most of my use cases. I usually use 201 when a new resource is created.
Breaking Down Redirect Responses
A lot of 300 responses are returned by web servers to do url redirection. Basically they get the response back and do any necessary redirection. The only time I’ve ever used these was when doing redirects through htaccess rules for search engine optimization rules.
300 – “Multiple Choices” – I’ve never seen this ever returned.
301 – Moved Permanently. Normally this is used to say that the url has changed and you should use it instead. This is usually used for search engine optimization reasons.
302 – “Moved Temporarily”. I don’t remember ever actually using this for anything.
303 – I’ve used this in the past when telling a browser to redirect after a successful POST or DELETE request.
304 – “Not Modified”. This is normally used when doing web caching.
Breaking Down Client Error Responses
400 – Bad Request, usually isn’t in a format the server can understand ie sending xml to a server that requires json.
401 – Unauthorized. Authentication is required and either isn’t valid or hasn’t been provided.
402 – Payment required. Most servers don’t use this but Google Developer API uses this when you go over the limit and Shopify uses it when a store is temporarily suspended for not paying their fees.
403 – Forbidden. Server is refusing to do anything with the request probably because the user doesn’t have the necessary permissions. In the past, I’ve seen this used when a duplicate record would be created.
404 – Item Not Found.
422- Unprocessable Entity. I like to return this when I’m validating that a request has all the details that are needed.
Breaking Down Server Error Responses
500 errors are usually an error that is caused by a problem with the server being setup or configured incorrectly.
500 – Internal Server Error. This is usually returned when there’s a problem with the request. Generally it’s nothing that the user has done.
504 – Timeout. This usually means that the server took too long to respond and cut off the request.
