What is HTTP?
HTTP is the protocol for text communication that rules the web. It being a protocol means there are strict rules on how it is used and what it can do.
What is it used for?
HTTP is used for transferring textual information between browsers and servers. This information is needed to load your favorite site, for example. And yes, for every page load the browser initiates an HTTP request and then waits for a response from the server. You rarely notice this non-stop ping-pong communication because the Internet is fast.
What is a server?
The server is where the code of the software product you are using lives. It's a computer on steroids that never sleeps and instead waits for requests that it can answer. Legends say that old IT wizards feed it coffee beans so your websites do not crash.
Are all HTTP requests the same?
No, they are not. In fact, there is an infinite amount of HTTP requests you can make but they do come in just a few breeds. The usual request is a GET request, meaning it only wants to read data from the server. There are also POST, PUT/PATCH, and DELETE requests which can respectively create, update or delete data from the server. By now you noticed that the difference lies in the verb we are using. In the IT world, we call this verb the HTTP request method.
How do HTTP requests differ?
The most obvious difference would be the URL. Let's take Wikipedia for example. It's homepage is wikipedia.org while the wiki page for Mount Everest is wikipedia.org/wiki/Mount_Everest. And you guessed it - changing Mount_Everest to Matterhorn gives us the URL for the Toblerone Mountain. The full URL is wikipedia.org/wiki/Matterhorn.
We proved that the URL is important but is that all? What else is there that matters? Well, not much that you can see in plain sight, so let's delve one level deeper.
In-depth URL recap
HTTP vs HTTPS
URLs actually start with the protocol and for most URLs that's either http://or https://. The difference lies in the s that stands for secure. And this s is impactful.
HTTP communication is simply text being transferred over the Internet. If you have access to the internet cable that carries it you could see the text - including your username, password, and payment card information. Sucks, right? The IT wizards thought so too and came up with HTTPS. It's the same old HTTP, however, it travels through the Internet encrypted. This encryption guarantees, through mathematical formulas, that no one but the server can decrypt the text... or at least within the next hundred years or so. I call this safe enough...
Domain name
After the protocol comes the domain name. In our case that would be wikipedia.org. The domain name is fixed for every site and is unique. There is no other wikipedia.organd all the content inside Wikipedia can be found under the wikipedia.org domain.
Disclaimer
There are things called subdomains and seeing them for the first time may be overwhelming. That's why I wanted to introduce both in advance. An example of a subdomain is en.wikipedia.org and, I am sure, you already figured out that en. indicates the English version of Wikipedia. There is also es.wikipedia.org for Spanish, de.wikipedia.org for German, and so on.
Subdomains are an advanced topic and internationalization is just one of the possible applications. Stay tuned for the advanced article to learn more.
Path params
Let's review the 'Everest vs Matterhorn' example yet again. wikipedia.org/wiki/Mount_Everest wikipedia.org/wiki/Matterhorn
Can you see the pattern? It's wikipedia.org/wiki/{some-mountain}. Arguably, if you replace {some-mountain} with the name of a mountain it should work. Let's try with K2 - the second-highest mountain... and indeed https://en.wikipedia.org/wiki/K2 works!
{some-mountain} is in fact a placeholder for the thing you want to view at Wikipedia. And it's not only mountains - it could be everything, like people and planets: https://en.wikipedia.org/wiki/Albert_Einstein https://en.wikipedia.org/wiki/Earth
The proper IT name for this placeholder is a path param. URLs are not limited to having only one, however, things get confusing with multiple and we will leave that out of this article.
Query params
Query params are not required but are extremely useful and easy to wrap your head around. They always start with ? and come in pairs separated by =. Let's not get too technical and continue with an example of a tire shop website.
The thought experiment begins with the domain best-tires.com and the query params ?season=winter. This gives us a complete URL of best-tires.com?season=winter. What will the server do?
The server parses the path param pair season=winter as season - the path param name and winter - the path param value. We have probably guessed the URL for viewing the shop's winter collection. Let's switch to the summer on and select tires that cost less than 200 but more than 200. The URL this time is as follows: best-tires.com?season=summer¤cy=USD&min_price=150&max_price=200
We obviously sent multiple query params, one for each of our filters, and separated them by the rules - with an &. The server parsed the following tire requirements:
- season is summer
- currency is USD
- minimum price is 150
- maximum price is 200
Our dream server may handle more query params than we can handle so let’s put a stop here. What's important is to remember that query params are extremely useful for filtering and always stay at the end of the URL.
Non-URL customization
There are two hidden ways for modifying the HTTP requests that I want to show you. One is via headers and the other is through the body. I won't go into much detail here so bear with me.
Headers
Request headers are hidden for a purpose as they mainly provide the server with context. For example - the browser and OS you are using or the cookie that proves you successfully logged in 5 minutes ago.
Server responses have headers too and some are incredibly handy. The one that comes to mind is responsible for automatically setting the cookie for you. Just imagine having to pass a secret code every time you want to view a new webpage...
There are also headers that increase the site's security or others that let your browser perform faster through caching. All in all, headers are extremely underrated because they operate under the hood and without causing issues.
Body
The request body is the place to put user input into. Its size limit is huge (in comparison to the query params) and is also hidden for the normal user. It's perfect for sending your huge comment, or this article, over the Internet. However, the body is a special place that requests of the GET method name cannot access. They must rather use query params for user-provided data.
Conclusion
HTTP rules the web and now you understand the king a little bit better. We are cooking up an article for those of you that want to experiment with HTTP so stay tuned for more. And until then have patience while surfing the Internet. Requesting and responding may sometimes take time.
Emil Kirilov - Co-founder at Lexis Solutions
Top comments (0)