Temos novidades que se aplicam aos seguintes triggers:
REST
HTTP
HTTP File
ANTES E DEPOIS
A seguir você pode ver algumas das configurações mais comuns dos triggers na versão anterior e na versão nova:
- Padrão com API Key
- Com API Key e JWT
- Sem segurança (API Key ou JWT)
Entenda o que significa cada campo nas configurações do trigger:
METHODS: métodos do protocolo HTTP (GET, PUT, POST, PATCH e DELETE)
Maximum Timeout: tempo máximo de resposta da chamada
External API: publica o API em um gateway externo
Internal API: publica o API em um gateway interno
API Key: necessário quando o API for consumido
Token JWT: necessário quando o API for consumido
Custom URI Path: campo onde é inserida a rota editável
Note que com o surgimento dos formulários você:
tem acesso a todas as configurações de antes
pode visualizar todas as opções de configuração possíveis
realiza os preenchimentos com mais rapidez e praticidade
QUAIS SÃO AS NOVIDADES AFINAL?
Exposição Interna/Externa de APIs
Agora é possível publicar APIs escolhendo se serão expostas externamente ou apenas internamente. Veja algumas possibilidades que esta nova funcionalidade proporciona:
Exposição externa: permite que os endpoints sejam acessados via internet. Ideal para implementação de estratégias de open API, para integrações com parceiros e sistemas externos.
Exposição interna: publicação de APIs acessíveis exclusivamente em seu Realm, permite que seus ambientes On premise utilizem APIs dentro da Rede através da VPN (Cloud Privada). Ideal para integrações que envolvam apenas sistemas internos.
Benefícios da mudança
Maior isolamento e segurança para integrações com sistemas internos
Possibilidade de versões externas e internas com diferentes níveis de funcionalidade
Customização das URIs
A grande novidade está na customização das URIs. Além disso, o uso que antes era somente externo, agora fica disponível também no seu Realm.
Depois que os pipelines são implantados, as suas URLs adquirem a seguinte estrutura:
https://{env}.godigibee.io/pipeline/{realm}/v{n}/{pipeline-name}
{env}: pode ser tanto o ambiente de produção quanto de teste
{realm}: corresponde ao Realm
v{n}: versão do pipeline
{pipeline-name}: nome dado ao pipeline
Vamos supor que criamos o pipeline "lista-produto". Levando em consideração o que comentamos acima, a sua URL terá a seguinte aparência:
O que vem depois de "v1" é a parte editável. No caso, escolhemos "lista-produto", que nos trará todos os produtos de uma lista disponibilizada pela empresa em questão. Agora você tem a liberdade de definir novas rotas. Acompanhe como:
1. Ative a opção "Additional API Routes".
2. Digite "/produtos" e aperte ENTER.
3. Pronto! Você tem uma rota alternativa, com um novo endereço:
https://test.godigibee.io/pipeline/empresa/v1/produtos
Você também pode acrescentar uma rota que recebe um parâmetro - por exemplo, "/produto/:id".
Se a URL acima for chamada, o seu pipeline receberá o valor de ":id" através do "queryAndPath", conforme este código:
{
"body": {},
"headers": {
"Host": "lista-produto:8080",
"apikey": "xxxxxxxxxxxxxxxxxxxxxxx",
},
"queryAndPath": {
"id": "1234"
},
"method": "GET"
}
Fique atento ao definir suas rotas adicionais. Conflitos dentro do mesmo Realm fazem com que seja difícil prever qual pipeline será executado. Por exemplo:
A (/produto)
B (/produto)
C (/:produto)
Quando pipelines diferentes têm URIs iguais (assim como os pipelines A e B), apenas um deles é executado. O mesmo acontece quando o request vem com o valor “produto” (pipeline C). Para evitar que isso aconteça, sugerimos que você adote um padrão de nomenclatura, inclusive para os requests.
Se você utilizar /:produto (conforme indicado no exemplo C), o caminho original de acesso ao pipeline será substituído.
Digamos que você crie um pipeline e o chame de pipeline-1. Assim que o ocorrer o deploy, a plataforma vai criar a seguinte URL: https://staging-test.godigibee.io/pipeline/digibee/v1/pipeline-1
E caso você utilize rotas adicionais e configure a rota /:mensagem, a URL http://staging-test.godigibee.io/pipeline/digibee/v1/ vai disparar o pipeline-1 considerando /:mensagem.
Nós recomendamos que você tenha cuidado redobrado nesse momento, pois essa rota vai sobrescrever qualquer outro pipeline que esteja no ar na versão 1 (v1). Com isso, por exemplo, o pipeline https://staging-test.godigibee.io/pipeline/digibee/v1/meu-novo-pipeline ficaria inacessível, pois /:mensagem o sobrescreveria.
O que nós aconselhamos é cautela na criação de rotas adicionais. Caso isso não seja necessário de fato, então sugerimos que você utilize algum prefixo. Por exemplo, /minha-rota/:mensagem. Assim, a URL original é preservada e os outros pipelines não são prejudicados.
Recomendamos também que você siga as boas práticas de REST. Clique aqui para conhecê-las.
Benefícios da mudança
Mais controle e segurança nesses tipos de trigger (REST, HTTP e HTTP File)
Rotas adicionais dão mais flexibilidade aos pipelines
O usuário evita retrabalho caso utilize legados com menos flexibilidade em termos de URI