How Browsers Make HTTP Requests | NYC PHP Developer

There’s a lot to know about web development. One important aspect is how requests are made. The browser is a client that makes HTTP requests on behalf of the user. This could be you, when visiting Netflix or visiting a news site. This could also be your potential customer visiting your website. To keep things simple, we use the term client. The web site, the computer with the resources, is the server. The web is built upon this client-server model, and it uses a protocol called HTTP to communicate between clients and servers. There’s a new version of the protocol called HTTP/2. It works largely the same way, but with some improvements. For simplicity, the term HTTP will be used.

It’s worth noting that while browsers are the most popular client, it isn’t the only client. There are REST clients that can create HTTP requests and analyze the responses. REST clients can be run as stand-alone applications e.g. PAW, or as plugins within other applications e.g. PHPStorm. You can write your own applications, within your favorite language, or create command line scripts that use cURL to interact with a server. Other client types won’t be discussed in this article. You should just be aware they are available. The focus here is on how HTTP works.

Scenes from a restaurant

With all the technology involved with a browser loading a web page, it’s easy to get lost in the details. It can help to use an analogy to simplify things. I’d like you think about your experience when you go to a restaurant. A nice restaurant. You deserve a good experience, after all. You’ve picked the restaurant, and traveled there. When you arrive, the hostess picks up a couple of menus, and escorts you to your table. Fortunately for you, a table is available. OK, now here’s where the analogy comes into play — with your interactions with the waitress. You the customer, are the client. The waitress? Another name for waitress, is a server.

Getting Things

The job of the waitress is to interact with you and to carry out your requests. She knows how the kitchen staff work, where things are kept, so you don’t have to. The restaurant would be a much crazier place if the customers just walked into the kitchen and got whatever they wanted. There are different types of requests she can execute for you.

The first and most common type of request is to get things for you — some silverware, ketchup, mustard. These are things that are largely pre-made. She can also get you some things that require some minimal assembly — A glass of ice water, a soda, a basket of bread. On the web, browsers use HTTP to make GET requests. A browser makes GET requests for things like downloading images, videos, or other static files are like the silverware and condiments. They already exist, and they just need to be retrieved. Downloading HTML files are like the ice water. Some light assembly is required, but is given to the customer as a whole. HTML files provide structure, content, and point to other resources e.g. images, CSS, video, audio. Each link in the HTML document is downloaded as a separate request by the browser. It’s the browsers job to display each of those downloaded files to the user, according to it’s location in the HTML document and uses the styling of the CSS to modify it’s appearance.

Placing Your Order

The next most common request type is called POST in HTTP. In our customer/waitress dynamic, POST requests are akin to placing your order. We haven’t talked about the server software. Let’s briefly discuss it now. The most popular web server is Apache, followed by Nginx, and a few others. The web server, Apache, is our waitress. Any requests that cannot handled by our waitress, are handed off to someone else. For POST requests, in our restaurant model, that means the cook. So who’s the cook? That would be your server side applications written in PHP, Python, Ruby, or other server side programming languages. This is where the work gets done — things are created, prepared, and arranged. When it’s ready, the cook hands her work off to the waitress, who gives it to you — the customer. The application could be anything — Laravel, WordPress, Rails, etc. The process will be same though. The Web server sees the URL is not for a file or a directory, so it hands the request to PHP who loads the index file e.g. index.php, which kicks off the loading of your application. Just like the waitress doesn’t know how to cook anything, The web server doesn’t need to know how things are processed. It doesn’t know about Laravel or WordPress. It just knows to hand things to PHP, and to grab the result. When things work as expected, we refer to it as the “happy path”.

One side note: Forms are often used to make request, using both GET and POST. When a form is used to send a GET request, the data is sent to the server as query parameters in the URL. Google Maps is a popular example of this. POST requests don’t write their data to the URL. Instead, POST requests send the content as the body of the request. Young developers sometimes use this fact to decide whether or not they want to use POST over GET. That thinking is a mistake. Instead, you should think about the purpose of the request. POST creates data, where GET retrieves data.

Status Codes

We know that nothing is ever perfect, all the time. Things go wrong. Your path is not always the happy one. HTTP has a set of status codes. Sometimes they represent an error, sometimes they reflect a misalignment of expectations. Other times though, they reflect the state of things e.g. Yup that happened. That’s why we refer to them as status codes — they represent both success and error cases.

There are 5 classes of statuses in simple terms

100-199: Keep calm, carry on
200-299: All is well
300-399: Things have changed
400-499: The client e.g. browser screwed up
500-599: The server screwed up

The happy path is represented by the “200 OK” status. All is well, and David Hasselhoff gives you an enthusiastic thumbs up. If you’ve heard people talk about SEO, the 301 and 302 status codes have come up in discussion. They mean “this thing has a new permanent URL”, and “this is temporarily available at this new URL”, respectively.

The 400s have the most codes, as the client has the most opportunities to make a mistake, or not meet the expectations of the server. The client can basically ask for anything. It’s up to the server to do it’s best to complete the request, and if it cannot, to inform the client why it cant be completed as requested.

The 500s happen on occasion. When you see a “500 server error”, usually something went wrong with the server application. A web developer will need to come in an find and fix the error.

Other HTTP Actions

Just like in a restaurant, there are other things you can do — you can update your order (PUT), and cancel your order (DELETE). There’s another HTTP verb called HEAD, which isn’t so obvious. The HEAD request is described as follows: The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. In our restaurant analogy, a HEAD request is sort of like having the waitress tell you how much the item costs, and the number of calories. You don’t get the actual item.

Summary

Thinking about HTTP, on top of everything else, can be overwhelming if you’re learning web development. Using non-technical terms helps to simplify things. Computer scientists often borrow concepts and terms from the real world, to make technology more relatable. Did you find this helpful? Let me know.