We have news regarding the following triggers:
REST
HTTP
HTTP File
BEFORE AND AFTER
Take a look at some of the most common configurations of the triggers in the previous and new version:
- Default with API Key
- With API Key and JWT
No security (API Key or JWT)
Understand the meaning of each field in the trigger configurations:
METHODS: methods of the HTTP protocol (GET, PUT, POST, PATCH and DELETE)
Maximum Timeout: maximum call response time
External API: publishes API on external gateway
Internal API: publishes API on internal gateway
API Key: required when consuming API
Token JWT: required when consuming API
Custom URI Path: field where the custom route is inserted
With the new forms you:
have access to all the previous configurations
can see all the configuration options
fill in quicker and more conveniently
WHAT ARE THE NEWS AFTER ALL?
Internal/External APIs exposition
Now it's possible to publish APIs by choosing external or internal exposition. See some possibilities this functionality delivers:
External exposition: allows the endpoints to be accessed via Internet. It's ideal for open API strategies implementation, integration with partners and external systems.
External exposition: publication of APIs accessible exclusively in your Realm, allows your On Premise environments to use APIs inside the Network through VPN (Private Cloud). It's ideal for integrations that involve internal systems only.
Benefits of the change
Greater isolation and security for integration with internal systems
Possibility of external and internal versions with different functionality levels
URIs customization
The big news is in the URIs customization. Besides, the use that was external only, now is also available in your Realm.
After the pipelines implementation, their URLs have the following structure:
https://{env}.godigibee.io/pipeline/{realm}/v{n}/{pipeline-name}
{env}: can be the production and test environment
{realm}: corresponds to Realm
v{n}: the pipeline version
{pipeline-name}: name given to the pipeline
Let's say we've created the "product-list" pipeline. If we keep in mind the comment above, its URL will have this appearance:
What comes after "v1" is the custom part. In this case, we chose "product-list", that will deliver all the products of a list enabled by the company in question. Now you're free to define new routes. Here's how:
1. Activate the option "Additional API Routes".
2. Type "/products" and press ENTER.
3. Done! You have an alternative route, with a new address:
https://test.godigibee.io/pipeline/company/v1/products
You can also add a new route that gets a parameter - for example, "/product/:id".
If the URL above is called, your pipeline will get the ":id" value through "queryAndPath", as the following code:
{
"body": {},
"headers": {
"Host": "product-list:8080",
"apikey": "xxxxxxxxxxxxxxxxxxxxxxx",
},
"queryAndPath": {
"id": "1234"
},
"method": "GET"
}
Pay attention to your new routes definition. Conflicts inside the same Realm make it difficult to foresee which pipeline will be executed. For example:
A (/product)
B (/product)
C (/:product)
When different pipelines have identical URIs (as pipelines A and B), only one of them is executed. The same thing happens when the request comes with the value “product” (pipeline C). To avoid it from happening, we suggest you to adopt a naming pattern, for the requests as well.
If you use /:product (as indicated in example C), the original path to access the pipeline will be substituted.
Let's say you create a pipeline and name it pipeline-1. As soon as it gets deployed, the platform will create the following URL: https://staging-test.godigibee.io/pipeline/digibee/v1/pipeline-1
And if you use additional routes and set the route /:message, the URL http://staging-test.godigibee.io/pipeline/digibee/v1/ will trigger pipeline-1 considering /:message.
We recommend you to be extra careful at this moment, once this route will overwrite any other pipeline that might be uploaded in version 1 (v1). Given that, for example, the pipeline https://staging-test.godigibee.io/pipeline/digibee/v1/meu-novo-pipeline would be inaccessible, because /:message would overwrite it.
What we advise is for you to mind the creation of additional routes. If it's not entirely necessary, then we suggest you to use some prefix. For example, /my-route/:message. That way, the original URL is preserved and the other pipelines don't get harmed.
We also recommend you to follow the good REST practices. Click here to know them.
Benefits of the change
Greater control and security in those trigger types (REST, HTTP and HTTP File)
Additional routes give more flexibility to the pipelines
The user avoids double work if using legacies with less flexibility in terms of URI