External API Request

Not too much theory?

Let's put this into practice. Let's open AppMaster, create an API request using it, and get a better understanding of how this request works.

Creation of External API Request

API requests are created in the “Business logic” section, in the “External API Requests” tab.

It's time to click “+ New API Request”

The name and description can be set to anything, they are for our personal use only.

Let's deal with the data that really matters.

The minimum required to create a request is to specify its Method and address (URL). Let's start with the last one.

URL

URL - Uniform Resource Locator. An address given to a particular resource on the Internet. The most familiar version of such a resource is an HTML page - we enter its URL in the address bar of the browser and open the desired site. At the same time, the resource itself can be anything, a picture, a video, a data set. The main thing is that this resource has a specific pointer - an URL to which you can send a request to get this resource.

Methods

Referring to the data at its address, we also indicate the method (you can also say the type) of the request, that is, we indicate what actually needs to be done with this data.

When we sent requests for the task of the first module, we received data. This is the GET method. This method is the most obvious method and also the only required one. Therefore, even if we did not specify it explicitly, it was still assumed by default that this was GET.

Let's see what other methods exist.

The HTTP standard itself does not limit the number of methods that can be used. At the same time, only some of the most standard methods are still used to maintain compatibility. There are 5 different methods that can be used in the AppMaster API requests.

GET. It's already dealt with. The method requests the provision of a resource, and receives data.

POST. To take data from somewhere, you first need to place this data there. The POST method does just that. Sends data to the server, creates a resource.

PUT. Similar to the POST method, but its job is to update the data. It does not create new data, but replaces existing data, updates it.

DELETE. As the name suggests, it deletes data.

PATCH. The method is similar to PUT, but is used to partially update the data, rather than replacing it entirely. For example, using the PATCH method, you can change the title of an article, or change the value of some parameter.

It is important to consider the fact that the server is not required to do exactly what is specified in the method at all. We can send the address of some page with the DELETE method, but this does not mean that the server will actually delete it. But, purely theoretically, he can do this with the GET command. Or do not change anything, but at the same time send data in response to POST. Just because the developer configured it that way.

This is where REST comes into play, which says that it's time to agree on the observance of the order, stop the mess and do exactly what is indicated in the method. At the very least, this should be the main task (although not necessarily the only one). E.g., when transferring the content of an article using the GET method, you can at the same time increase the counter of the number of its views by 1.

So, we figured out where the data is located and what can be done with it. Let's go further, let's see what other components the request can have.

URL Params

URL Params. There are situations where we only know part of the URL. An example is the articles on the Appmaster.io website. The starting address for all articles is the same - https://appmaster.io/blog/. But then each article has its own title and, accordingly, its own individual part for the exact indication of this particular article.

In such a situation, URL Params are used. We prescribe the general part immediately, and leave the rest to be decided in the process. As a result, the URL is written in the form https://appmaster.io/blog/:id/

The known part is written as is, and the variable part is placed after the “:” sign. The name of this variable part (already without “:”) is added to the list of parameters. In this case, there can be several variable parts, and their location is anywhere in the URL.

Query Params

Query Params. Remember when we sent a request to boredapi.com in the first module? And in addition to the address, additional data was prescribed. That was the Query Params.

They are written after the URL and are separated from it by a “?” sign. The name of the parameter, the sign “=” and the value of the parameter itself are indicated. If several parameters are used at once, they are separated by the “&” sign.

However, when specifying parameters in AppMaster, you don't have to think about the request rules. Everything will be properly formatted automatically. You just need to specify the name of the parameter itself and add it to the list.

Query Params are used when the data source is the same, but the data itself may be different. For example, Boredapi contained a huge list of things to do. But we were only interested in those that are intended for one person and that's what we specified in the request parameters.

Another use case is to limit the amount of data. For example, we could access some list, but request only the first 5 entries from it. This quantity can also be a query parameter.

Another option is an access key. You may have used this option in module 1 when referring to Alphavantage. Data could be obtained only after registration and sending a personal key in the request parameters.

Pay attention to the pages that you visit on the Internet, you will probably find various parameters in them too. For example, open the weather page of Ventusky.com, in the query parameters geographic values ​​​​of latitude and longitude are sent.

Headers

Headers. Request headers. Usually headers contain service information about the request (meta-information). Headers allow the server to get more information about the client that is requesting the data. The headers can contain information about which browser is being used, what encoding the response is expected to be in, in what language, the exact time of the request, and more. In the case of access to protected data, the headers may contain an authorization key.

In most cases, headers are optional. Even in the first module, we already made a request where we did not specify any headers (although this does not mean that the request was actually sent without them).

Body

Body. Request body. GET requests usually do without it, but if we want to send some data to the server, send a POST or PUT request, then this data is placed in the request body. At the same time, you can place data of any complexity in the request body, for example, send a video file, and not be limited to some number or a text string.