HTTP(S) action step

Need to access data from an external source? The HTTP(S) step is the solution for you.

After reading this article, you'll learn how to:

• Configure the HTTPS step

• Retrieve data from a different place

What is HTTP(S) step?

The HTTP(S) step is one of the standard action steps within the action builder. It's also one of the most powerful steps in the standard set of steps since it allows you to connect to various services, be it retrieving-, sending-, updating-, or deleting information.

Think of it as a bridge between your application and another. You send a request to the other side to retrieve a package (some data), and maybe you need to sign a security form(a password/key), to show it's you who is picking up the package (the data) and then bring it back to your side.

Each way on the virtual bridge is set up with the HTTP(S) step, and per step (GET/DELETE/POST/PUT) you will have to define the action your application needs to take for virtual routing over the internet.

HTTP(S) step options

The HTTP(S) step has a few major options: Methods that define what the step needs to do, URL parameters options to navigate to the correct environment and make sure you can safely pick up your virtual data, and the schema model to assist the application in structuring the data you retrieve so that you can immediately work with it.

Methods

Methods describe what task needs to be done when calling out to another application. Often when working online, we GET data from other environments, here is a more in-depth explanation using a bank account as an example:

• GET is like viewing your account details

  Imagine logging into your bank account to check your balance or view your transaction history. You're not changing anything, just getting information about your account. GET requests are like that, they're used to retrieve information about a website account from a server without modifying it.

• POST is like adding money to your account

  When you deposit money into your bank account, you fill out a form with the amount and submit it. You're adding new information to the system. POST requests are like that, they're used to create new website account data on a server.

• PUT is like transferring money to another account

  If you want to transfer money from your bank account to another account, you'll need to initiate the transfer. You're changing the balance of your account. PUT requests are like that, they're used to update existing website account data on a server.

• DELETE is like closing your account

  If you no longer need your bank account, you can close it and remove all your information. You're removing yourself from the system. DELETE requests are like that, they're used to remove website account data from a server.
  ​

URL & parameters

After deciding the method, you will build up the URL and provide the information necessary to connect to the other service, the first part to fill in, is the Header option. Within the Header option, you define items like the content type you are requesting, or providing the authentication token that is requested by the opposing party you are connecting to.

Make use of the application configuration segment to safely and dynamically work with authentication keys within your application.

After defining the header information, you move on to structuring the URL you are connecting to by defining the Protocol, URL and other parameters.

The protocol determines if you are using a safe (HTTPS) or unsafe (HTTP) connection. The URL option allows you to set the URL of the remote source you want to connect to, within the URL you can set the URL and Query parameters.

When looking at the example use-case in the screenshot, the complete URL looks something like this https//.jsonplaceholder.typicode.com/posts/{{id}} .

Let's dissect this URL to get an idea of what we are dealing with:

URL parameters are used to dynamically build the URL with defined values, in our example case you could either navigate to the /posts endpoint, but you could also navigate to the /users endpoint of the source.

The Query parameters are used to filter the response you are asking for on other values, let's say we are looking for users from the country of the Netherlands, where applicable.

The URL would be like this: https//.jsonplaceholder.typicode.com/users?country=netherlands. It will now retrieve all users and initially ask for users from the Dutch country if possible.

Response

After setting up your method, prefered body or matched a schema model with the request. You can determine how you want to save the response. 

In cases you want to dissect your response, or simply save it as a flat piece of text, you can use the text option. When you expect to retrieve 1 single object from your request, you can use the object option. 

When expecting a collecting of data, you can use the array option, allowing you to use the response as a set of data.

For some use cases you also want to save the response code, for example to know which request returned a 404 (not found) request instead of a 200 (success) request. You can use the Response code as option to determine how you want to save this data.

Using the data

Once the data is being sent back to you, you would preferably have that defined in a way that your application can use it. You can select a schema model you have created in your application, in which the response from the HTTPS request will be mapped to match a Betty Blocks model, allowing you to use it in the application.

Once all is set, you can retrieve your response with the Response as option, and use it throughout the rest of your action.

Building an HTTPS action

We have created an in-depth guide on retrieving test data using the HTTPS step, in this article we'll go over the example settings you need to use and how to test retrieving data from an external source.

Use the information from this article to safely set up connections to other sources, and to turn your application into a multi-source data management tool!