How 🤷‍♂️ a web server 🖥 works?

Made using Canva

In previous section we have learnt about how things in real-world work and basic concept of Client-Server architecture. Let’s go ahead and learn how web servers actually work.

A web server works the same we write our normal programs but there are few additional things in a web server. You can assume them as meta data for now but it’s not exactly that. Let me show you the difference.

A computer program

As you already know, what happens in a computer program, we are not gonna discuss anything about that. Let’s take a look at how a REST API behaves. 👇

A HTTP request

You might be thinking what the heck is all this stuff. Don’t worry we will go through each of them and understand them clearly. As you can see a network call involves two things, a Request and a Response. The place(url) to which we make HTTP request is called an endpoint.

Request

1. Method
2. Host/IP
3. Request Headers
4. Body
5. Path
6. Query
7. Params
8. HTTP Version
9. Scheme

1. Method

Assume it as the operation you want to perform. If you want to fetch/get some posts from the server, then you use GET method for that, likewise for deleting a post, the DELETE method. Here is a list of methods we use most often.

GET, PUT, POST, PATCH, DELETE

2. Host/IP

Basically when you get a server from hosting providers like Digital Ocean, Linode etc., they don’t give you something like fayaz.com, but they can give you only the IP address of the server, something like 104.54.74.5 🖥 which holds connection to the server, it’s your task to get a domain from DNS(Domain Name Server) providers like GoDaddy, NameCheap etc., and then make mapping to the server. (You can find detailed instructions from the hosting provider’s website, we will discuss deeply about this later).

3. Headers

Headers are like informative key-value pairs, which will introduce the API request to the server. Didn’t get an idea? Think about something like a phone call, whenever someone call you, their phone number is visible on your screen which makes easy for you to understand who is calling you, from which country… Here you’ll something similar, just look at common request headers below.

Common Request headers:

• Authorization
• Content-Length
• Content-Type
• Accept

Let’s consider an Authorization header, generally in OAuth 2.0 protocol we use this header in two ways, one to access(Bearer) the API and other to refresh our token(Basic). Take a look at below example which demonstrates how we use headers and tokens in OAuth 2.0,

OAuth 2.0 using Tokens and accessing API using Tokens

Here, I am using the JSON, content type to exchange data so we should add the headers:

Content-Type: application/json to tell the server how to read the values as json, Accept: application/json to tell the server send response as json

4. Body

This is the place where a server and client exchange the actual data. Consider the above example, in the first request there we are sending username and password in json format. And in the third request, we are getting user details in the same json format. We can send data in any format, developers also used to send data as plain text, xml before.

5. Path

As the name of it, it’s quite the same thing. The path where we want to communicate with the server. Consider a sample API which has two paths configured, users and posts respectively.

We make requests to respective paths to get the correct data. When we call the users path, it will return us the users data available in db and posts will return posts available in the db. We’ll consider the example at the end of this section.

6. Query

This is similar to body, but key-value pairs which are directly send in the request url. Consider example at the end of this section.

7. Params

This is similar to query field, but without any key and sent along the path following a slash(/). Consider example at the end of this section.

8. HTTP Version

We don’t have to worry much about this as a beginner, generally most of the API’s run on HTTP/1.1 or HTTP/2. This will be considered during the configuration of the web server.

9. Scheme

This is related to the Transport layer security, if we don’t have an SSL certificate, our scheme will be HTTP and if we have SSL, then it will be HTTPS. It is recommended to use https scheme in production level API as it provides end-to-end encryption and decryption. Feel free to get more information about SSL on the internet.

Request showing usage of path params

Here we are trying to make a request to the server, which should return the user’s data whose id is 37ded9815cb3.The API path ends as api/v1/user but the id which we sent as considered as param and the server configuration will be something like this api/v1/user/:userId . If the server is configured as the above way, then it identifies the id which we sent as userId for the above request. They are considered as path-params.

Request showing query params

Here we are requesting the server to return the user data whose id is 37ded9815cb3. The server will identify the query params and will make use of uid to make a match request in the database for user data.

Response

1. Status line
2. Body
3. Headers

1. Status line

HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:

1. Informational responses (100–199)
2. Successful responses (200–299)
3. Redirects (300–399)
4. Client errors (400–499)
5. Server errors (500–599)

There are many status codes, but you don’t have to remember all of them, there are few status codes used frequently. Checkout this link for more info.

Consider the examples below taken from MDN(Mozilla) website and Firefox’s Network tab:

Screenshot showing 304 Status code

Screenshot showing 200 status code

You can also the path of request, who triggered the request, type of request, size it has downloaded and in what is the response time. Try switching to your browser’s Network tab to see your website’s network map.

2. Body

This will have the data we have got from the response, whereas if you consider the pictorial examples shown in Headers of Request section above, you can find we are getting the user data as response his name, email… As discussed in the Request section, the server will return the data in which client can understand and parse the data.

3. Headers

There won’t be much difference in headers here, but we might expect few headers that were automatically added like server, date… which depends on mostly the configuration of the server. If you look back at the example discussed in Request section, you can find that we are getting access and refresh tokens in response headers. Take a look at MDN websites response headers below.

Response headers of MDN website

Other articles in this series include

1. Introduction to REST API and Web servers.
2. How web servers (this article)
3. Why we should use REST API.

Thank you for reading the article, feel free to follow for more such stuff and don’t forget to smash the clap button.