DEV Community: Alex Winder

HTTP Status Codes

Alex Winder — Sun, 05 Jun 2022 10:46:48 +0000

HTTP status codes are a fundamental part of the modern Internet. Whether you are consuming APIs or requesting remote resources, you will be making use of HTTP status codes.

As a developer these status codes can tell you a lot and help you to identify issues in your application, and also to be able to handle better error messages for your users.

You may already be aware of some of these, probably the most famous is the 404 Not Found. But did you know that these codes have very precise categories?

HTTP Status Code Categories

1xx - Informational Response

Any status code which begins with a 1 is an informational response and are typically issued while the request continues processing.

Some informational response codes include:

100 Continue indicates that everything so far is OK and that the client should continue with the request, or ignore it if it has already finished.
101 Switching Protocols indicates a protocol to which the server switches. With a 101 response the protocol to which the server switches is specified in the Upgrade header which is also sent from the client. One example of a 101 Switching Protocols status code would be when you make a connection to a WebSocket server.

2xx - Successful

Any status code which begins with a 2 is an indication that the requested action from the client was received by the server, it was understood and accepted.

Generally the most common successful status code is a 200 OK. A 200 is the standard response for successful HTTP requests.

Some successful HTTP status codes which you may see include:

200 OK indicates that the request was received and understood by the server and accepted.
202 Accepted indicates that the request made has been accepted for processing, but this processing has not yet completed.
204 No Content indicates that the server was able to successfully process the request, but there is no content to return to the client.

3xx - Redirection

When a status code begins with a 3 this means that it is redirection. This indicates that the client must take additional action in order to complete the request.

Some of the most common HTTP redirection status codes include:

301 Moved Permanently indicates that the initial and all future requested should be directed to a given URI.
302 Found (Moved Temporarily) indicates that the client should look at a URL. The difference between this and 301 is 302 suggests that the requested resource will only temporarily be available from the new URL, but 301 suggests it is permanent.

If you are involved in SEO then you will typically be making use of HTTP 301 and 302 status codes on your servers quite often.

4xx - Client Error

Any HTTP status code which begins with a 4 is an indicator that an error has been caused by the client.

Some of the most common HTTP client error status codes include:

401 Unauthorized indicates that authentication is required but has failed or has not yet been provided.
403 Forbidden indicates that the request was valid and was understood but the server is refusing action. This is similar to a 401 Unauthorized, however a 403 might be where a user has authenticated but is attempting to request a resource which they don't have permission to access, whereas a 401 is where the user hasn't authenticated at all.
404 Not Found is quite possibly the most famous HTTP status code of them all and it indicates that the requested resource could not be found on the server.
418 I'm a teapot is a status code which is returned by teapots which have been requested to brew coffee.

5xx - Server Error

When a HTTP status code begins with a 5 this indicates that there was a problem with the server and so it was unable to fulfil the request.

Some server error HTTP status codes which you may see include:

500 Internal Server Error is a generic error message which is often returned when the server is not configured to handle the response.
503 Service Unavailable is when the server cannot handle the request, often because it is overloaded or is down for maintenance. A 503 status is typically a temporary state.

How can I view HTTP status codes?

As status codes are a fundamental part of browsing any website, the simplest way to view them would be to open up the Network Monitor on your browser whilst viewing the website. This will show you the state of the requested resources as you load different parts of a website.

Firefox

To view the Network Monitor on Firefox press Ctrl + Shift + E. This will open a window on your page with the "Network" tab highlighted. Then if you refresh your page you will see all of the resources which are requested with that page.

Chrome

To view the Network Monitor on Chrome press Ctrl + Shift + J. This will open the console window. Then select the "Network" tab. Then refresh your page and you will see all of the resources which are requested with that page.

So, you have a new website...

Alex Winder — Sun, 22 May 2022 14:39:26 +0000

You've just finished building your shiny new website and you're ready to release it to the world. You upload it to your webhost or perhaps you change the visibility to public. You then wait for Google to crawl it, or perhaps you submit it to the Google Search Console. However, your website doesn't show in the top result, or even in the first few pages on Google.

You do some research and find that you need to look into something called SEO. There are tools online which show you things you need to improve on, but the reality is the majority of these tools are just making a best guess as search engines don't publish the metrics they use for indexing their results.

You set out to do some Search Engine Optimisations to your site. This shouldn't take long.

You start with making sure that your site is responsive between devices, making sure things are laid out nicely on mobile, tablet, desktops and everything else inbetween.

Afterwards you make sure that all of your assets are compressed, minified and reduced to their smallest possible size to reduce your page load time and how long it takes for your site to become interactive. You install a caching service or CDN to reduce the amount of time spent downloading files from your site.

You then find out that the colour scheme and your choice of page elements are not quite as accessible that they could be, so you spend time tweaking colours to not only match your brand but also to improve on the user experience for those with accessibility difficulties. You resize all of the buttons, headings, paragraphs, images, menus, and everything else to give the best possible accessibility to your users. Whilst you're doing this you remember reading about HTML semantics and so you make sure that the format of your website is built so that screen readers can properly parse the structure.

Your SEO report is getting better at this point and you are rising up the search results, but for results which you didn't ever intend to. So you head back into your content and rewrite pages to target specific keywords, give all of your images the correct descriptions and change headings to better describe the content. You set up some more descriptive URLs but you make sure not to forget to set up 301 redirects from the old URL. You check that your sitemap is correct so that search engines aren't storing incorrect or old data.

After all this you then need to begin writing blog posts to improve on the reach of your site and to show up for more search terms.

At this point you're feeling pretty smug with yourself and your website is finally on the first page, or if you're lucky then you're result number 1 for your search terms. But to your horror after a few weeks Google announces some core changes to their algorithm which appears to completely wipes you off the results page, and so you find yourself tweaking your site more in the hope that it improves your ranking.

The reality is that SEO is a dark art, and website results rankings are dependent on search engines who rarely (if ever) give any indication as to the metrics they use to rank websites. There are SEO "specialists" which claim to be able to guarantee result number 1, but these are often charlatans or will give you results which you never asked for. There are best practices to improve your chances, but only those who have deep understanding of the Google algorithm can guarantee a result.

Here are a few online tools which can aid with your own SEO improvements:

The above links are not a guaranteed way to improve your site, but do aid with some basic best practices.

Complicated code is not clever

Alex Winder — Wed, 16 Mar 2022 20:00:01 +0000

I remember when I first started learning to code, I would be reading snippets online would find myself having to read things over and over again to be able to understand them.

The problem wasn't with the logic of the code or with what it was doing, it was how it was written.

Consider the below PHP code snippets, which do you think is more readable?

function json($arr){echo json_encode($arr); die();};

$a = array('t'=>time(),'un'=>$ufn.' '.$uln,'tn'=>utn($ui));

json($a);

function outputArrayAsJson(array $array)
{
    echo json_encode($array);
    die();
};

$response = [
    'time' => time(),
    'userName' => $user->firstName . ' ' . $user->lastName,
    'teamName' => getUserTeamName($user->id)
];

outputArrayAsJson($response);

This is obviously subjective, but I think generally more people (developer and not) would be able to understand the latter solution over the former.

Using the above examples which are written in PHP just scanning over the code of each you can quickly understand what is happening in the second snippet much faster than the first.

You're unlikely to need to go searching through your codebase to find what getUserTeamName($user->id) does, its name and arguments are already indicative of its use case. However compare this with utn($ui) which is not so clear. I can guarantee that if you left this codebase for any period of time you would need to go back to the utn function to remind yourself what it does.

There are going to be things referenced in any language which are outside of our control, such as bundled standard libraries, but the things which we do have control over should be produced to as high a standard as possible.

I believe that code should generally read like a story or a book. If you had to constantly keep flicking between random pages of a story would you be likely to finish the book? Almost certainly not. As developers it's important to not only write efficient, but also, understandable code. Doing so reduces technical debt and makes the development experience far more enjoyable.

You don't need to be an expert to write clever code.

Here are my top tips for writing clever code:

Conventions

Pick one and stick to it. There is no right or wrong, tabs or spaces, camel-case or snake-case, it doesn't matter - just create a convention stick with it. Consistency is the key.

Whitespace

Bunching up concatenations or blocks makes them harder to read. Similarly keeping short statements on one line, and splitting longer statements into multiple lines makes them easier to follow without needing to scroll.

// These are bad
$variable=$a+$b;
if($variable===101){
return rand(1,5)+2;
};
functionWithLotsOfParameters(true,[1,2,3,4,5],$ui,null,MyObject::class);

// These are good
$variable = $a . $b;

if($variable === 101)
{
    return rand(1, 5) + 2;
};

functionWithLotsOfParameters(
    true,
    [
        1,
        2,
        3,
        4,
        5
    ],
    $ui,
    null,
    MyObject::class
);

Descriptive Names

Make your code the comment. All names which you have control over as a developer should be descriptive. A function called outputArrayAsJson(array $array) tells the developer exactly what it does without even needing to read the logic inside the function. You are never going to remember exactly what your code does when you revisit it in a year, so make the code readable.

Comments

Comments should explain why you needed to do something, but not how. Code changes often, but comments are commonly missed when the logic changes. I've lost count the number of times where I've copy/pasted code between 2 files and forgotten to update the comment context.

Scopes

Make use of scopes where possible and try to group common logic together. Grouping portions of similar code together, such as in a class, makes things much more maintainable and avoids code repetition. Only use global scopes as an absolute last resort.

// This is OK
http_response_code(404);
die('Page not found');

// This is better
class Response
{
    public const HTTP_NOT_FOUND = 404;
    public const HTTP_NOT_FOUND_MESSAGE = 'Page not found';
};

http_response_code(Response::HTTP_NOT_FOUND);

die(Response::HTTP_NOT_FOUND_MESSAGE);