For the fullstack developer who is secretly a backend developer — don’t be scared of web communication protocols (HTTP, REST, WS)
As I mentioned in my previous article (For the fullstack developer who is secretly a backend developer — don’t be scared of CSS), I was scared of the frontend. Besides the CSS, which still appears in my nightmares every once in a while, I also found terms like TCP/IP, HTTP, RESTful API, and WebSockets to be very intimidating. I already mentioned in the past why I think you should, as a fullstack developer, know essential aspects of the frontend, so let’s dive into it.
I have to start by saying that I took an “Introduction to the computer networks” course, but it didn’t emphasis the same parts I needed for my everyday work.
I won’t show code examples because the internet is flooded by those, I’ll just talk about the concepts in my wording, in the hope it will make things more understandable to you. (if you do find code examples necessary, let me know and I'll add some!)
TCP/IP:
Before I landed my current position as an SWE (Software engineer), I interviewed at Intel as a student, just starting the networks course I mentioned before and was asked about this subject. Of course it didn’t go well, and this word gives me bad vibes ever since.
I don’t find it important for your everyday work with HTTP messages, but I’ll talk about it so you won’t have that clueless face when it is mentioned.
The TCP (Transmission Control Protocol) is a part of the transport layer (the lettuce).
After the application layer (the tomatoes) gets the data from your program (using HTTP protocol, in our case), it talks to the transport layer through a port (does port 80 sound familiar?), and the TCP transfers packets to the internet layer (the cheese), which is the IP (Internet Protocol) part of TCP/IP, and then the network layer (the meat) sends the packets to their destination.
Another connectionless (what is connectionless? we’ll talk about it later) communication protocol is UDP (User Datagram Protocol). A word about it: TCP is more reliable but UDP is faster. You are probably wondering what is a suitable scenario for giving up on reliability, so a good example would be watching movies online (legally, of course) because it’s not noticeable if you miss a packet of data every once in a while, which is translated to frames in the video stream.
For more information about TCP/IP, watch this video.
HTTP:
We all are familiar with this word. It appears as a prefix of every link — but what does it actually mean? OK, I’ll be more accurate: HTTPS appears at the beginning of every link. HTTPS is the secured version of the HTTP protocol (for more information about HTTPS click here).
HTTP is the most used protocol in the world! it is TCP/IP based protocol and its purpose is allowing web-based apps to communicate and change data (documents, images, etc.).
If two computers want to exchange data, they do it in a request-response cycle. The client is the one making the request (usually a web browser) and the server is the one giving the response.
HTTP is a connectionless protocol! the client sends a request -> disconnects -> the server has a response ready -> connects -> sends->disconnects.
HTTP can deliver any sort of data! that the two computers can read.
HTTP is a stateless protocol! The client and server only know about each other during the current request. Like a fish’s memory (actually that is a myth, according to google). So, every communication between them is like the first time (ohhhh so romantic).
why HTTP? because it is the most convenient way to move data on the web quickly and reliably.
HTTP messages are plain text and easy to read.
The HTTP message is composed of three parts: start line, headers, and body.
As mentioned before, there are two types of HTTP messages: request and response.
Request:
In the start line, we see three parts: the method (GET), the URI (/somedir/page.html) and the HTTP version (HTTP/1.0).
There are several possible methods, the most commonly used are GET and POST.
In our example, the user is asking for an HTML file. The URI is telling the server where to find the desired file ( AKA in which directory).
I won’t get into details about the headers because I think its fields are pretty straightforward. I’ll just mention that the host is the server we’re connecting to.
Response:
In the request start line, there are two parts: HTTP version and request status. In our example, the request succeeded so we got 200. Other common statuses are 304 — not modified, 401 — unauthorized, 404 — not found.
(You can see more status codes here).
APIs:
API stands for Application Programming Interface. It is a way to let software components interact with each other, and it’s like a menu of actions you can use. It’s a set of methods and attributes, for example a cellphone API would contain a microphone, speakers, cameras as attributes, and calling, listening to music, taking pictures, saving pictures as methods.
Web services are a set of rules and technologies that enable two or more components on the web to talk to each other -> Web services are APIs!
Web API:
An API over the web which can be accessed using HTTP protocol. It is a concept and not a technology. We can build Web API using different technologies such as Java, .NET etc. For example, Twitter’s REST APIs provide programmatic access to read and write data using which we can integrate twitter’s capabilities into our own application.
A note about ASP.NET Web API: The ASP.NET Web API is an extensible framework for building HTTP based services that can be accessed in different applications on different platforms such as web, windows, mobile etc.
REST:
My best friend started working in a new place not so long ago, and they have a REST person there. She was wondering what that means, and we both didn’t know the answer. So — this one is for you, girl:)
REST = REpresentational State Transfer. REST is a specification that dictates how distributed systems (= a system whose components are located on different networked computers) on the web should communicate. Therefore — it is a way to implement and use the HTTP protocol.
RESTful API:
This is an API that follows the rules of REST specification. There are six constraints the API must follow in order to be RESTful, and you can find them here.
Back to my friend — I think that the REST person’s job is to adjust the API they create for their product to satisfy the restrictions of a RESTful API.
WebSockets:
WebSocket is a computer communications protocol, providing full-duplex (=bidirectional) communication channels over a single TCP connection. It differs from HTTP by the fact that it provides a persistent connection between a client and server that both parties can use to start sending data at any time. HTTP protocol is connectionless and the communication starts by the client sending requests to the server.
Here is a cool animation of how a WebSocket connection is being established:
The client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response. Once the connection is established, communication switches to a bidirectional protocol which does not conform to the HTTP protocol.
So, when to use HTTP requests and when to use WebSockets?
In our project at work, we use both. WebSocket is more complex and intended to be more persistent. You can use HTTP when you need to upload the page in the browser, but in order to get updated, you should probably use WS.
Let’s take Facebook, for example: You can use an HTTP request from the browser to get the home page, but use a WS connection to get notified when you have a new message. Another implementation option is that the browser will send requests every once in a while to check if there are any new messages, but it could load on the server (especially when dealing with multiple users), and it’s not very real-time (which maybe not a big deal with Facebook messages, but could be critical in a command and control system).
The reason it could load on the server is that establishing an HTTP connection requires establishing a TCP connection (SYN, SYN/ACK, ACK) and then sending a GET request with a pretty big header.
When using an open WS, on the other hand, you simply receive the response (without any request) and it comes with a much smaller header.
Keeping a connection open (WS) and establishing a new connection (HTTP) are two costs that need to be considered when deciding on between the two protocols.
To conclude:
All the information here was just the tip of the iceberg. My goal was to make it short and easy, help you enter this world, and now you can continue learning by yourself!
Please let me know your thoughts: Was it appropriate for beginners? Did it leave you with taste to learn more? Does it look less scary now?
Blogging is my hobby, so I happily spend time and money on it. If you enjoyed this blog post, putting 1 euro in my tipping jar will let me know :) Thank you for your support!
