APIs
Overview
APIs are a collection of endpoints, organized into different stages.
They play an integral role in the deployment of a workflow, providing organization and security capabilities with the help of API-specific keys.
This tab stores and manages the APIs you create and use for the deployment of your workflows.
The APIs tab
Stages and Endpoints
A single API can have multiple stages (parallel versions) working exactly the same way but running in different environments.
Endpoints, on the other hand, are strings that correspond to the URLs which you need to hit so that the API can be triggered for a particular stage or called from other systems.
API Gateway
Each API and stage can have different endpoints, with basic HTTP methods supported.
You’ll have copies of all endpoints in each stage that you build. The same endpoint may map to a different set of workflows that are powering that endpoint.
As a result, APIs are considered key to maintaining a unique API Gateway system designed to provide external as well as internal access to the Pliant environment.
This could allow users to contribute to the backend part of web applications without even having to know how to program. It’s the power to create small services and publish them to other teams as building blocks of what they want to achieve.
A direct result of deployment is the generation of a universal and unique flow URL. Users can change the name of the flow later and still use the same URL to access it.
Note!
Unlike regular workflows, deployed flows are considered active and are counted towards your license.
You can check relevant limitations for your account in About Pliant.
Before you begin
From your Pliant instance, navigate to APIs.
Make sure you have permission to interact with this page.
Features
Find a specific API using the Search bar.
2. Sort APIs by name, the user who created them, authentication type, or description.
Procedure to create
You can create an API in just a few steps.
Click the Create API button on the top-right and fill in the fields for the window that opens.
Name - the name of the API.
General Settings - a section which expands settings concerning the basic functioning of the API.
a) Worker group - the worker group the API is going to run on.
b) Description - optional description for the API.
Authentications - a section which expands settings related to the authentication service the API is going to enforce.
a) Pliant - only logged-in Pliant users can access the API.
- Myself only - only you as a logged-in user can access the API.
- Everyone in Pliant - every logged-in Pliant user can access the API.
- Pliant Users and Roles - specific users and roles can access the API.
When this option is selected, admin users can get auto-suggestions when searching for users and roles.
Link users to roles by clicking the respective Add user/Add role buttons.
Indications of whether the users and roles exist and are active are shown - the chips are colored differently according to the user and role state.
Non-admin users can also add any user or role, but they’ll get roles auto-suggestions only.
b) Anonymous - this virtually means no authentication. Anyone can access the API.
c) API Keys - only people with a link and a specific API key can access the API.
When this option is selected, you need to create a unique API key by clicking the Add API key button.
This triggers the section to expand further down, with fields for creating an API key.
Once you name the key, click the V button to save your changes.
The value of the key is automatically generated and available to see and copy.
If needed, apply actions on the specific API key through the three-dot button, such as editing its name or deleting it.
d) Workflow - with this option, you need to select an endpoint and a stage pair on which an existing deployment is based.
Тhat pair pair can then start a workflow which defines who can access the API.
Keep in mind!
It’s not possible to use the Workflow authentication without having created your API first.
For more information, read here.
Advanced settings - if clicked, it expands to optional overridable settings which apply to everything inside the API.
а) Flow should run - the way the workflow will run (synchronous or asynchronous)
b) Run real time - decides whether the flow should run with logs or in real-time.
c) Statistics as part of result - decides whether there will be statistics included as part of the flow execution result.
d) Response timeout (in ms) - time interval after which communication between the worker and API is lost.
e) Message timeout (in ms) - time interval after which a message indicates that all jobs the worker is executing will be suspended or killed.
f) Error status code - the status code of the error generated after the timeout.
g) Enable API request logging - allows API requests for deployed API endpoints to be logged, which helps in understanding the action(s) taken by the gateway.
This option will flood the database with logs if forgotten
2. When done, click Create to finish creating the API.
You’ll be automatically taken to the Deployment module where you can further manage the API and use it in the deployment of a workflow.
API actions
There are two actions you can perform on an API. They’re accessed within the three-dot button in the Actions column.
Edit - This allows you to make changes to the API.
It opens the Workflow Deployment module, in which you need to navigate to the Settings tab to change the provided API properties.
Once you’re done with the edits, click Save.
2. Delete - This removes the API but will ask you for confirmation first.
To delete multiple APIs, select their check boxes on the left and click the Delete button at the bottom-left corner.
