General Information

The last module ended with the creation of the first business process. We figured out how to create process logic, accept specific input parameters, perform calculations and issue an answer. It remains to answer the main question. How to activate the created business process and put it into operation?

To solve this problem, endpoints are intended - key points of interaction with the application. In the first modules, we have already interacted with external APIs. This was possible thanks to the presence of endpoints. They were described in the documentation, and we read it and understood what method and what URL it is necessary to send a request to access a specific resource.

For understanding, let's look at the implementation of endpoints using a specific example. In the third module, the database model was created. At the same time, simultaneously with the creation of tables, endpoints were automatically created to interact with them. Let's go to the endpoints section (on the left panel) and look at them.

In the example of the "city" table with information about cities, it can be seen that it already has 6 endpoints for basic data operations.

• GET /city - getting all data from a table
• GET /city/:id - getting data about the city with the specified id
• POST /city - adding a new record to the table
• PUT /city/:id - complete replacement of the record with the specified id in the table
• PATCH /city/:id - partial replacement of a record with the specified id in the table
• DELETE /city/:id - deleting a record with the specified id from the table

General settings

You can open the settings for each endpoint and study it in more detail. For example, consider the endpoint GET /city/:id

The picture we see is very similar to what we have already seen when creating a request to external APIs. In one case, we only accessed a ready-made endpoint, and now we are creating and configuring this endpoint ourselves. To configure, you must specify:

1. Request method. In this example, this is the GET method.
2. Request URL. The first part with the path to the server is not specified. It is the same for all application endpoints. It is enough to specify only the ending (/city). The URL parameter is also specified here. The endpoint is designed to receive information about a particular city, so its id written after “:” is passed as a parameter.
3. Endpoint Groups. This parameter does not affect the operation of the endpoint in any way and is intended only for the organization's convenience. All endpoints can be divided into thematic groups (folders). In this example, the "city" group contains all the endpoints for working with data on cities.
4. Business Process. This is the most important configuration item and is something that could not be seen in any way when sending a request to the endpoint. The indication of the business process determines what this endpoint will do. At the same time, the endpoint itself can remain unchanged, it will receive all the same requests at the old address, and at the same time, if the business process is replaced, it will perform a completely different function. Business processes for basic database activities are created automatically. They are called system business processes. Such BPs cannot be changed but can be replaced at any time with BPs created independently, with custom business processes.
5. Input/Output variables. The created business process uses various input and output variables, but the endpoint does not have to use all of them. Part can be disabled or configured so that different endpoints access the same BP, with an individual set of variables. The request and response type (Request / Response type) is also configured there. Most often, this type will be JSON, but, if necessary, other options can be used, such as XML or Render File (this type of response is used in endpoints for working with files).

Middleware settings

General settings are sufficient for creating and further using the endpoint, but additional parameters can be used if necessary. The most important of these is the activation of Middleware with an Auth token.

Its use allows you to deny access to this endpoint to users who have not been authorized or do not belong to a certain group (for example, access can be granted only to administrators and denied to other users).

Logging and output settings

In addition, you can use the settings on the Settings tab to additionally log headers or the request body, as well as to hide from the response those fields whose values are not set.