Writing an OpenAPI Specification is the first step when creating APIs with Frends. The OpenAPI Specification works as the blueprint in which the API Endpoint, parameters and payloads are defined. The Specification itself doesn't have any functionality, so next we need to create Processes for each API Endpoint. The Processes will implement the functionality of the API. Processes linked to each of the API Endpoints are called Linked Processes. Without Linked Processes your APIs don't have any real functionality. Creation of Linked Processes is also a requirement for viewing API Specification UI, since you have to have at least one active Linked Process to open the API Specification UI.

In the following modules we will be looking at how to create Linked Processes and what you need to take into account when creating Linked Processes. In addition we will take a look at how you can utilize Subprocesses to enable hosting of different API versions simultaneously.

You can start creation of a Linked Process from API List View by first selecting the API to which you want to create a Linked Process and clicking "+ Create new Process" from API Endpoint to which you want to create the Linked Process.

Clicking the button will open the Process Editor. Trigger, Return and Throw Elements are automatically generated according to OpenAPI Specification. Name and description of the Process are also automatically generated. Now you can start implementing the Endpoint's functionality like you would implement any other integration Process.

After the functionality is implemented and Process is saved, API List View will show that there is a Process Linked to the API Endpoint. You can also see if the Linked Process is active or not. To view API Specification UI you need to have at least one active Linked Process.

As mentioned above, Trigger, Return and Throw Elements are automatically generated from the OpenAPI Specification. This doesn't mean that they behave in a way which you have defined in the OpenAPI Specification, since the functionality of the Linked Process has to be created. Next we will be looking at couple of things you should consider when you implement Linked Processes.

In the OpenAPI Specification you can define parameters and body which should be sent to the Endpoint. But parameters and request body are not validate when the Linked Process is triggered. This means at it doesn't matter what kind of parameters and body are sent to the Endpoint if you don't validate the data, Process will trigger anyway if authentication is successful. Validation of parameters and request body has to be implemented in the Linked Process.

How parameters and request body should be validated depends on the use case. If your Endpoint take request body in JSON, you can use Frends.Json.Validate-Task to check if the request body contains all required properties and the values are in correct format. This way you can prevent injection attempts. Validation of parameters depend on the use case. For example, if a query parameter named "date" has to be in a specific format, you need to verify that the provided date follows the format. If there are some headers that are required for the Process to work, you need to check that those headers exist and they contain acceptable values.

Execution time of a Process depends on the functional implementation. When you are hosting APIs you need to consider the execution time of a Process. If a Linked Process takes long time to execute, sender of the request might think that the Endpoint is not responding and terminates the request. This means that the Linked Process will also terminate. To prevent this scenario you can use Intermediate Return Element. The Element allows you to send a response to a requester before the Process has finished executing, preventing the requested from terminating the Process execution.

When you generate the Linked Process from OpenAPI Specification, Returns are automatically generated according to OpenAPI Specification. However, the response body is just a template of the data that should be returned to the requester. This means you have to create the actual data that will be returned to the requester. The response body has to be mapped according to use case and the content of response body has to be configured to each Return-Element. For example, if your API Endpoint returns JSON to requester you need to map the data you wish to return to requester to JSON format and configure your Return-Element to use that created JSON.

The next article is Introduction to Using Subprocesses in APIs.