The purpose of the HTTP protocol

The purpose of the HTTP protocol

Understanding URLs and Websites

We use websites every day and access them using unique URLs, right?

For example, we type in the URL https://www.google.com to access Google's website.

Google website

Similarly, we type in the URL https://www.instagram.com to access Instagram's website.

Just like the address of our home, on the web, a URL (Uniform Resource Locator) acts as a unique address for a website on the internet.

But have you ever wondered how URLs actually work?

How does a website load when we enter a URL into the browser?

Let me quickly break it down.

A web application like Google.com is stored on a web server so that people on the internet can access it and search the web.

This server is linked to Google’s domain name (google.com).

So when you type https://www.google.com in your browser and hit enter:

  • Your browser figures out which server is hosting Google’s website.
  • It then sends a request to that server, asking for the webpage.
  • The server processes the request and responds by sending back the webpage content.
  • Your browser then displays the page for you.

At the end of the day, it is a request-response cycle that you're already familiar with.

And what makes this request-response process work? The HTTP protocol.

In other words, the browser sends a request and receives the response via the HTTP protocol.

So, what exactly is the HTTP protocol?

HTTP (Hypertext Transfer Protocol) is essentially the universal language that allows different software applications to communicate with each other over the internet.

How HTTP protocol works

You can think of HTTP as the postal service of the web:

  1. You send a request (like mailing a letter).
  2. The server processes it and responds (like receiving a reply letter).

The web operates on this request-response model, too:

  1. You enter a website URL into the browser, requesting its webpage.
  2. And the server that is hosting the website will respond with the content of that page.

In other words:

  • The browser says: “Hey server, I want this page.”
  • The server responds: “Sure! Here you go.”

And this simple request-response mechanism is the foundation of almost everything we do on the internet.

How does this relate to APIs?

Here's the best part.

This isn't just how websites work.

This is also how APIs work.

“Oh! Nice!”

Yeah.

Just like websites are hosted on servers, APIs (Application Programming Interfaces) also run on servers.

And just like a website, an API has a URL where you can send requests to get, post, put, and delete information.

For example, we have been working with the Google Sheets API since the beginning of this course, right?

Here is the URL for accessing the Google Sheets API:

https://sheets.googleapis.com/v4/

Similarly, if we want to get PageSpeed Insights metrics for our doctors' websites, we use this API URL:

https://pagespeedonline.googleapis.com/

And as you can see, we need to use a URL with HTTP protocol to access the Google Sheets API or any API for that matter.

Also, if you notice, although Google Sheets API and PageSpeed Insights API are maintained by Google, each API has its own unique URL.

API URLs are called as API Endpoints

Strictly from a terminology standpoint, an API URL is referred as API Endpoint in most API documentations.

Here is a great definition from IBM: An API endpoint is a digital location where an application programming interface (API) receives API calls, also known as API requests, for resources on its server. API endpoints are components of APIs and are most often in the form of URLs, or uniform resource locators.

Long story short

APIs listen for incoming HTTP requests and respond with the requested data.

Behind the scenes, even the official apps on Make.com, such as Google Sheets or Airtable, work by sending HTTP requests.

The only difference is, the apps provide a user-friendly interface so you don’t have to manually craft each HTTP request.

Anyway, now that you understand how HTTP and APIs work together, in the next lesson, we will understand what makes up an HTTP request.

We'll break it down into:

  1. The API Endpoint (the address of the API)
  2. The method (GET, POST, PUT, DELETE)
  3. Headers (extra information about the request)
  4. Query parameters (options passed in the URL)
  5. Body data (data sent with the request)
  6. Response body (the response data you receive from the API)

If you can understand these core components, you will get the ability to work with any API on the internet, even those without official Make.com apps.

See you in the next lesson!