Introduction to HTTP

Unit introduction

Welcome to the first unit of the “Introduction to HTTP” course, which is a part of Make Intermediate.

Throughout this course you’re going to explore some of the HTTP modules within Make. The HTTP app is an incredibly useful tool to have in your skill set, and will take you to the next level of using Make.

In this unit we’ll focus on the concept of what is HTTP, and what is an HTTP request.

This unit is theory based, meaning that you don’t need to build any scenarios at this point.

HTTP basics

What is HTTP?

HTTP (Hypertext Transfer Protocol) is a set of rules that allow the browser on your computer or phone (e.g., Chrome, Safari, Firefox) to communicate with a web server (the place where websites are stored). It’s like a common language that the browser and server can both understand.

These actions are managed by HTTP requests. There are several types of HTTP requests that serve different purposes, but the most common requests are GET and POST. We will be exploring GET and POST in this course.

Let’s think of GET in a real-life scenario: you order a package for delivery from AmaKeZon. You provide what you want in the order (fashionable clothes, a good book, a nice hat), the quantity of each, and your address. AmaKeZon will then deliver the package to your address.

This is similar to how HTTP works with your browser. When you type in your browser or click https://academy.make.com/, your browser communicates with the web server, making an HTTP request to view the webpage. As you request the package to be delivered to your address, so does your computer/browser request the particular website to be delivered to you.

What is HTTPS?

You may have noticed when you view a weblink, it sometimes starts with HTTPS. HTTPS stands for Hypertext Transfer Protocol Secure, and means that you have secure communication over the internet. To simplify, it adds an extra layer of encryption to protect any data being sent or received between a browser and a website.

Think of this as sending a package to a friend: when it is encrypted it is locked and only your friend can open it. Anybody who tries to open or tamper with the package is unable to.

When you visit a website, it will almost always use HTTPS. All connections in Make are HTTPS secure.

Can I GET any website?

Using the HTTP → Make a request module, you can obtain data from any website. For example, you can use the GET request on https://www.make.com. You’ll learn how to do this in the next unit.

When you make such a request, you retrieve a single bundle containing data items, arrays, and a long string. Under the +Data (Long string) is the HTML for make.com.

Think of HTML as “the recipe” for a webpage.

Why is HTTP important?

Now that you have an idea of how HTTP works and how you can get data from websites, let’s look at how this fits into Make and what you can do with it.

HTTP is important because this is what Make uses in most apps and modules in your scenarios: it calls third-party APIs. Sometimes a specific Make app doesn’t exist, so you will use the HTTP module to configure the call yourself.

Before delving into what HTTP can do, you first need to understand what an API endpoint is and what it does.

What is an API?

API stands for Application Programming Interface. APIs are created to help software applications to communicate with each other.

If HTTP is a language for communication between different systems, then API is a language for communication between different applications.

Make and API

Developing with APIs has many steps and complexities, which is where Make is so useful.

Each application has its own “language”, and Make connects to these applications via their APIs. This allows Make to connect all these apps together retrieving and sending data between them.

Think of 2 APIs as people who speak different languages, and Make being the translator between them.

API endpoints

Within each API are resources which allow an application to share data with other applications. These resources are known as endpoints.

Under the hood, Make utilizes API in the form of applications, and each module represents a different endpoint. To provide access to different resources, different endpoints are provided and utilized.

For example, Google Sheets defines an API to make its resources accessible to other applications.

Different endpoints allow access to different resources (e.g. search or update a row). This API understands HTTP as means of communication.

The Google Sheets Make application talks to the Google Sheets API via HTTP.

If the app that you use is not listed in Make but has API endpoints, then the HTTP modules will allow you to utilize them.

Example

Let’s look at an example from an earlier scenario build in the Make Academy.

The Make Foundation and Make Basics use cases utilize the API endpoints of the Weather app and Google Sheets.

In this example the Weather app will retrieve the weather (GET current weather endpoint), and Google Sheets will store data (POST Add a row endpoint), but both of these apps do not have the endpoints to send communications, or to export an invoice.

This is why Make is so powerful - it will let you connect different software applications and allow data to move and communicate in different systems to handle your needs within one platform.

Request methods

As mentioned earlier, if there is an application that isn’t available in Make but has API endpoints, then the HTTP module will allow you to utilize the API endpoints.

It will do this by using different HTTP request methods. The most commonly used request methods are GET and POST.

In the later units in this course, you will build scenarios using both GET and POST.

GET

GET is the method of retrieving information from an API endpoint.

When you make a GET request you are asking a server to provide you with the data of a resource.

You can use the GET method in a number of ways, for example:

GET the weather from a weather API, giving you real-time or forecast data.
GET content from a social media post to embed in an article.
GET flight information, such as flight schedules or delays.

Note: the GET method is not the same as the get() function, covered in the previous course.

POST

The POST method in an API can be used to send data.

It is used for creating resources, or performing actions that result in a change on a server.

You could use the POST method to:

Submit an order or feedback form.
Create records in applications such as Google Sheets, or Airtable.
Send a message.

Others (optional)

There are a few other HTTP methods that can be used, but we won’t be using them in this course. These are:

PUT: this is used for updating existing objects. For example, an administrator could update the profile fields of every user in their database from “Learning Automation Student” to “Make Academy Learner” using the PUT method.
PATCH: this is used to replace parts of an existing object. Such as, updating “Make Academy Student” to “Make Academy Learner”.
DELETE: it is used to delete objects, such as delete the profile of a specific user.

With different request methods you should always check the third party API and follow their API documentation when choosing an endpoint and HTTP method. For example, the POST method can also be used to get data in some services, such as search-orientated services and GraphQL APIs, where you actually POST a query and the response contains search results.

Status codes

Every time you make an HTTP request, the server provides a status code which represents the outcome of your request. It will provide information on whether a request was successful, encountered an error, or needs further investigation.

There are more than 70 codes – we’ll look at the most common ones here, using the example of making an order with Amakezon.

200 Success

200 = success. The server received and successfully processed your request. You placed an order with Amakezon and they delivered it to your door = status 200.

400 Bad Request

400 = bad request. The server cannot understand or process your request, as there is something wrong with the request itself. But the scenario will still execute, just with no data! You place an order online and accidentally change the quantity to "-1" - it’s a bad request because Amakezon can’t send you "-1" of a product. = status 400.

404 Not Found

404 = not found. The resource that you have requested can’t be found. For example if you visit https://www.make.com/amakezon/thispagedoesnotexist, you will receive a 404 - page not found status code.

500 Internal Server Error

500 = internal server error. This means that something has gone wrong with the server that the website administrator needs to fix. An update on the Amakezon webpage has caused a temporary problem which their developers are fixing.

Handling HTTP Errors in Make

Most apps within Make will stop a scenario with a 400 error, but HTTP is the exception. You can stop a scenario from executing by telling Make to classify any status code that does not start with a 2 or 3 as an error.

Let’s look at an example - a scenario has a Google Form and sends the data to Slack. If this scenario encounters a 400 error, it would still process the scenario but contain no data. This would leave the Slack message missing important information. This applies to other error types too, not just a 400 error.

To enable this, toggle the Show advanced settings button, and select Yes for Evaluate all states as errors (except for 2xx and 3xx).

An API in action within Make

Let’s look at this very basic use case and what each of the API endpoints will do. You do not need to build this scenario.

Paula manages an outreach project where she engages with users based on their experience of the service her team provides.

She uses 3 different apps to accomplish this - Google Forms to collect feedback, Airtable to store it, and Slack to communicate with members of her team if they need to engage with the customer based on bad feedback.

Google Forms

Google Forms has numerous modules - for this scenario, the team uses the List Responses module. They run this scenario once per day in order to identify their workload.

The List responses module talks to a Google Forms API to retrieve this data.

However, Google Forms can’t communicate with Airtable or Slack directly. So the team will use the API endpoints of other modules instead.

Summary - The team request the values of all the form submissions from the API, which gets them and sends them back to Make.

Airtable

In Airtable, this will create a record of the users’ feedback, along with their email address, date, the rating and any additional comments they included.

The Create a record module talks to an Airtable API to create this data.

Summary - The API will create a record of the information that the team wants, based on the data from the endpoint of Google Forms.

Filter

The filter here is used to alert the team if a user rates the service less than a 2 out of 5 rating.

While the filter is not an API, it’s a crucial part of the scenario to ensure the right data is being analyzed.

Once data is in Make, you can use the functions, filters, Tools, modules etc., which do not send any requests, but they process data within Make.

Summary - Any bundle containing a rating of ‘less than or equal to 2’ will pass through the filter to the next module.

Slack

In Slack, if data passes the filter, a message will be created stating:

Hi team, please engage with the customer: Contact details: [Customers email] Score: [Rating] Comment: [Comment]

The Create a message module talks to a Slack API to send this message.

Slack is a messaging service - its main purpose is communication, but it doesn’t have the depth of database features like Airtable.

Summary - The API will create a message to send to the team, containing information Make passes to it from the Google Forms or Airtable module.

Example of a scenario using HTTP and API

Now let’s imagine a situation where Paula had to create the same scenario in Make, but neither Google Forms nor Slack exist in Make as apps yet. You do not need to build this scenario.

She can use HTTP modules to connect to the API endpoints of Google Forms and Slack. Note that this example is to explain the concept of HTTP modules – you would typically use a more secure type of call for HTTP requests (API key or OAuth2) which will be covered in a later course.

Google Forms

Paula will use an HTTP → Make a request module, utilizing a GET request method to retrieve the data she needs from Google Forms, using the API endpoint to List Responses.

This will retrieve the list of feedback comments.

The data in the output bundle produced will look the same as the Google Forms bundle.

As this module successfully executed, it would return a 200 status.

Slack

She then uses the message API endpoint in the Slack app to send a message to a group of users, and maps the same information as the previous scenario:

Hi team, please engage with the customer: Contact details: [Customers email] Score: [Rating] Comment: [Comment]

As this module successfully executed, it would return a 200 status.