Know your HTTP Status — A cheat sheet for HTTP Status Codes 🌐
An investment in knowledge pays the best interest — Benjamin Franklin
As web developers, we spend most times either sending a request(front-end/Client) or designing responses for requests to a server(back-end/Server). It’s highly efficient if we all should have ample HTTP status code(which is the protocol the web runs on) knowledge.
What is an HTTP Status Code?
Fernando Doglio, in his book — REST API Development with NodeJS defined a status code as:
a number that summarizes the response associated to it.
If you are like me, you’ve spent most times googling about what a status code means (maybe not for 404, but wait do we even know what that means as well?) when you make a request to say, a REST API(Don’t worry, nothing to be ashamed of 😀).
Why this Cheat Sheet?
I think proper knowledge and usage of the appropriate HTTP Status codes would enable back-end and front-end developers to better understand themselves in a project.
Below is a cheat sheet for the most common HTTP status codes you will come across as a developer: 😉
P.S: The cheat sheet is an excerpt from Fernando Doglio’s REST API Development with NodeJS. Thanks, Fernando for such a great book.
200 — OK ✔️ 💯
Ok. The request went fine and the content requested was returned. This is normally used on GET requests
201 — Created 🐾
The resource was created and the server has acknowledged it. It could be useful on responses to POST or PUT requests. Additionally, the new resource could be returned as part of the response body.
204 — No Content 👌
The action was successful but there is no content returned. Useful for actions that do not require a response body, such as a DELETE action.
301 — Moved Permanently 🏃
This resource was moved to another location and the location is returned. This header is especially useful when URLs change over time (maybe due to a change in version, a migration, or some other disruptive change), keeping the old ones and returning a redirection to the new location allows old clients to update their references in their own time.
400 — Bad Request 👎
The request issued has problems (for example, might be lacking some required parameters). A good addition to a 400 response might be an error message that a developer can use to fix the request.
401 — Unauthorized 🚫 ✖️
Especially useful for authentication when the requested resource is not accessible to the user owning the request
403 — Forbidden ✖️ ⛔️
The resource is not accessible, but unlike 401, authentication will not affect the response.
404 — Not Found 🔍 🔎 🔦
The URL provided does not identify any resource. A good addition to this response could be a set of valid URLs that the client can use to get back on track (root URL, previous URL used, etc.).
405 — Method Not Allowed ✖️
The HTTP verb(e.g POST, GET, PUT etc)used on a resource is not allowed — for instance, doing a PUT on a resource that is read-only.
500 — Internal Server Error 🙈
A generic error code when an unexpected condition is met and the server crashes. Normally, this response is accompanied by an error message explaining what went wrong.
Conclusion
The above HTTP Status Code is by no means exhaustive i.e we didn’t cover them all just the most frequently seen and used. For a list of the exhaustive list of all HTTP Status Code visit the link below:
You can also download a pdf version of the cheat sheet here:
Hope the above status code is helpful to you as you go on your hacking journey
