Emails / Email Course (6) Understanding HTTP Status Codes

Hello, {{ subscriber.first_name | default: "friend" }}! 👋

So a very clever user has decided to play hacker on your precious website.

They attempt to make an unauthorized POST and it's up to your server to stop them.

We can tell the browser not only that this request has failed, but why it failed.

This is where HTTP status codes come in.

I'm assuming you've probably worked with status codes before. I know you've seen at least one.

🚨 404 🚨

The infamous "Page not found"! HTTP codes are a great, succinct way for a server to let us know why something did (or didn't) work as expected. In the case of a 404, it's because the resource doesn't exist.

In the case of our friend the hacker, our response would be a 405.

405 tells the browser that a POST is not allowed for that URL.

The entire range of 400-499 status codes will tell us that the client did something wrong with the request.

To paraphrase a classic Tech-Twitter-Tweet, we can sum up HTTP status ranges as follows:

Responses are grouped into five classes:

As a frontend developer, it's important to understand status codes so that you can translate responses into a UI that makes sense to your user.

As an aspiring backend developer, it's important to send the right status codes to help those who have to work with your server and APIs.

A good user experience needs both sides of the stack to buy-in and work together.

The HTTP response is a perfect example of how we can make that happen.

Challenge

There are a lot of HTTP codes available, but you may not have use for all of them in your projects just yet.

Review the status codes and consider which ones you might use as a backend developer, based on the projects you’ll be working on.

What kind of requests from a client will your server be responding to, and which status codes will be most appropriate?