How Computers Talk: A Crash Course on Protocols
By: Sebastien Filion
Tags: Web Development, SaaS, Backend As A Service, Backend, Startup

In our previous article Introduction to Web Application “Backend”, I introduced the role of a server as a remote computer that is permanently connected to the internet. I also talked about some common use cases for software backend: how the frontend communicates with the backend to store and receive data, and how some backends can also communicate with other backends. Today, I am going to dive deeper into the mechanics of these interactions: how frontends and backends communicate with one other. In essence, how computers talk to one another, via the use of something called “protocols”.

The word protocol can be defined as “the accepted or established code of procedure or behavior in any group”. Not a very intuitive definition.

Alright, let’s try again with an everyday analogy: imagine you going into a coffee meeting with a professional contact for the first time. As you approach the person, you, as a well-mannered individual, open up the conversation with a greeting and a firm handshake — something along the lines of “good morning!”, “guten morgen!”, or “早上好!” When you are both ready to order coffee, you’ll likely say “please” and “thank you” to the barista waiting attentively behind the counter. Like us humans, computers also have established protocols to govern their interactions.

Some of the most well-known and widely used protocols are:

HTTP(S) : to connect to the web

: to connect to the web SMTP : to send emails

: to send emails POP3/IMAP : to receive emails

: to receive emails uPnP or Plug and Play: to connect devices (e.g. allowing devices like your printer and laptop or smartphone to automatically detect one another)

Like us humans, computers also have established protocols to govern their interactions…with HTTP(S) being the most omnipresent protocol in today’s world.

Introducing HTTP(S): The Standard Protocol of the Web

HTTP is probably the most omnipresent protocol in today’s world. Each time you type in the address bar of your Chrome, Safari, or Microsoft browser, you encounter it as the initial “http://” or “https://” (the “s” stands for secure) that comes before the web address.

Each time you type in your browser “https://www.google.com”, you are unknowingly making what we call an HTTP request.

With each HTTP request, this is what happens behind the scene:

You, as a client (someone or something who wants a service), make a request to a server (aka. someone or something who provides a service) in order to GET a web page located at www.google.com When the server receives your request, it will decide the most appropriate way to fulfill it. In this case, the server will send a response in the form of the Google landing page back to you. The exchange is completed.

Like our earlier coffee meeting analogy, your conversation doesn’t end with this first interaction. After ordering an espresso, you’ll likely ask for some sugar and a napkin. Like humans, your HTTP request conversation will typically continue with the following actions:

The client makes a request to the server to GET the Google logo image The server retrieves the logo image and sends a response carrying the image back to the client

And voila, you now have that Google home page comfortably loaded on your browser screen.

Up until now, the client has only engaged in one type of action: GETting content (the Google logo image) from the server. However, the server may support other methods: GET, POST, DELETE, PUT and PATCH. Using the same address, the meaning of the request will change if we swap the method of the request:

GET https://www.google.com/logo.png — I want to retrieve an image named “logo”

https://www.google.com/logo.png — I want to retrieve an image named “logo” POST https://www.google.com/logo.png — I want to create an image named “logo”

https://www.google.com/logo.png — I want to create an image named “logo” DELETE https://www.google.com/logo.png — I want to remove an image named “logo”

https://www.google.com/logo.png — I want to remove an image named “logo” PUT https://www.google.com/logo.png — If it doesn’t already exist, I want to create an image named “logo”

From time to time, a server request can also fail, and that is why a response always starts with a status code. The most infamous status code is probably the all-too-familiar 404 NOT FOUND, followed by 500 SERVER ERROR.

Here’s a list of the most common status codes that come with each server request and their meaning:

200 OK: The server successfully fulfilled the request 403 FORBIDDEN: The server understood the request but it refused it, probably because it is private data 404 NOT FOUND: The server could not find the resource that was requested 500 SERVER ERROR: The server encountered an error when trying to fulfill the request 503 SERVICE UNAVAILABLE: The server can’t fulfill the request at the current moment

Understanding protocols is the first step towards understanding how a well-designed backend fits into the larger context of a SaaS product. This foundational knowledge is not only a critical building block for your dev team, but is increasingly becoming an essential skill needed for product managers and non-technical business users.

Do you have any questions on the above topic? I’d love to hear from you, my readers! Don’t hesitate to leave a comment below, or send me a direct message on LinkedIn.

About the Author

Sebastien Filion is the Co-Founder and Tech Lead of DMFX Darkmatter. He is a serial entrepreneur and senior software engineer with over 10 years of experience in the Montreal startup scene. He led technical teams at three SaaS startups and advised on 11 early-stage startups over the course of his career.

DMFX Darkmatter is a PaaS startup based out of Montreal, Canada. Our tools abstract common backend components into a seamless experience for SaaS product teams. Follow our launch journey on our Facebook and LinkedIn channels.

Images courtesy of pexels.com