How Client-Server Communication Works: For Dummies
6 min read
Some point in your life, You may have had connected your Mobile device to your friends Mobile device via Bluetooth or Lets say you did. You can even send a file or receive a file or Accept an incoming file or Reject or Close the connection. You can do various actions.(or lets say methods). Here we do not care how your image file or audio file is being sent from your Mobile to your friend Mobile. All you care about is weather it is successfully reached or not.
Here these two Mobile devices are able to communicate/send or receive data via Bluetooth Protocol (as both the devices have Bluetooth Protocol Stack implemented). You don't care how it is working internally, you just use the above discussed actions(or methods) and get your work done.
Similarly, your web browser needs a way to communicate with another browser or application. Your browser should be able to Receive and Send data to another web browser (or application). Here comes HTTP (Hyper Text Transfer Protocol), which is an application level protocol, that sits above communication protocol TCP/IP . So if you browser has to send/get any data that your are reading now, HTTP plays the role (with few other underneath protocols). What are the different actions here ? Read this to speak HTTP.
Image Source: MDN
Now, when you type some web address like apple.com, your browser (Chrome, Safari, Firefox, Edge etc) sends some request to another computer (server), server will send back some data/images/files, and browser will parse, and now you can see all the products with beautiful images. Okay, will my request directly reaches Apples server ? Nope. Read this if you want to know.
Typically, HTTP request / response handshake is
|browser requests||server returns|
|HTML page||an HTML file|
|a style sheet||a CSS file|
|an JPG image||a JPG file|
|data||data (in XML or JSON)|
These Servers are built and Maintained by Companies like Apple/Google/AWS/Digital Ocean/ where all the data will be hosted. Some are not open to public and some are.
Lets put the same in an example. So, there is a nice Restaurant around. Restaurant owner has few Servers (or Bearers) working for him. You decide to visit and go to this Restaurant, For the restaurant owner you are a Client. So, You reach the restaurant which is on a particular street and building, you find restaurants beautiful carpets, nice paint, nice decorations and you feel nice. You find a table to sit and order what you want to the Server. Server goes back inside to bring what you ordered, Meanwhile you may make a call or play a game or just do nothing. Once the food is ready, your Server is back with food and it is served, and you Consume the food, and leave the Restaurant.
If we break this story further down,
- there is restaurant on a particular street/building -> Unique Address, called 'IP Address' which is in digits. As it is difficult to remember we use domain names that later gets translated. We use web address in browsers.
- you reach the restaurant via road -> your Internet connection
- restaurant has many rooms and floors -> built with HTML
- restaurant has beautiful carpets/wall paints/decorations -> built with CSS
- there is a table to sit and eat in one room -> webpage with some user actions/entry
- there are restrooms in another room -> another webpage
- lights are running when a switch is enabled, water runs when tap is opened -> JS can make this runnnig
- you are able to communicate to server and request food by saying GET that food-> send Request to Server via JS through HTTP using GET method. Beware that Server could also say OK (food if available) or BAD Request (Sorry Food Not available).
- the food is being prepared -> Server Computer is reading the data
- server is able to get food back to you -> get Response from Server via HTTP (can be multiple responses) and JS parses the data.
- you eat -> data from Server is being read/viewed
- you leave the place -> close the website.
Browsers communicate with Servers using HTTP and they understand HTML, CSS, JS
Using HTTP, you can Create, Read, Update, Delete Operations on the Server.
Just like 'GET', other HTTP Methods are
- GET (Read)
Requests using GET should only retrieve data and should have no other effect.
Ex: Returns Item Inventory list, Find Purchase order by ID
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.
same as GET, except it does not have response body.
- POST (Create)
POST requests are used to send data to the Server. Data is stored in the request body of HTTP request
The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.
Ex: Place an Order for an Item
- PUT (Update/Replace)
The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI does not point to an existing resource, then the server can create the resource with that URI.
- DELETE (Delete)
The DELETE method deletes the specified resource.
Ex: Delete purchase order by ID
The TRACE method echoes the received request so that a client can see what changes or additions have been made by intermediate servers.
The OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.
The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.
- PATCH (Update/Modify)
The PATCH method applies partial modifications to a resource.
Just like Server saying 'OK', HTTP response codes are
1xx (Informational): Request received, continuing process.
2xx (Successful): The action was successfully received, understood, and accepted.
3xx (Redirection): Further action needs to be taken in order to complete the request.
4xx (Client Error): The request contains bad syntax or cannot be fulfilled.
5xx (Server Error): The server failed to fulfil an apparently valid request.