Thanks for your feedback!
EDIT
Internal API Call
O interceptor Internal API Call permite invocar uma chamada interna com base nas configurações estabelecidas.
|
Imagine que, para uma determinada API chamada "ConsultaInformacaoVenda", você necessite que a requisição passe por uma autenticação simples de login/senha. Você já tem uma API para esse tipo de autenticação, chamada "AutenticaUsuario", que deve estar cadastrada previamente. Como você já tem uma API exposta ("ConsultaInformacaoVenda") e também já conta com uma API que faz todo o controle de autenticação, não se faz necessário replicarmos a lógica de autenticação para dentro do fluxo da API exposta. Ao invés disso, podemos adicionar o interceptor API Internal Call no fluxo da API "ConsultaInformacaoVenda", que redirecionará as requisições da "ConsultaInformacaoVenda" para a "AutenticaUsuario". Com base no retorno da autenticação, o interceptor então decidirá se irá continuar ou abortar o processo. |
Configurando o interceptor
Para configurar este interceptor, basta arrastá-lo para o fluxo de requisição e preencher os campos com as informações desejadas, como mostrado na imagem abaixo.
| Não é possível utilizar este interceptor no fluxo de resposta, apenas no de requisição. |
-
Variable Name: define o nome do interceptor Internal API Call, sendo único por fluxo. É através dessa nomenclatura que a resposta da chamada pode ser recuperada de dentro do mapa
$call.contextVariables, sendo necessário um custom interceptor para isso, como mostrado abaixo. -
API: API que será invocada.
-
Revision: revisão da API que será invocada.
-
Resource: recurso a ser invocado.
-
Operation: operação a ser realizada.
|
Só é possível invocar uma API que esteja implantada no mesmo ambiente da API em cujo fluxo você está adicionando o interceptor. Se pensarmos nas APIs do exemplo de uso acima, para chamar a API "AutenticaUsuario" é necessário que ela esteja implantada no mesmo ambiente que a API "ConsultaInformacaoVenda", que é a API que contém o interceptor Internal API Call. Se você quiser invocar uma API que não esteja implantada no mesmo ambiente, primeiro faça o deploy dela no ambiente desejado. Lembre-se que é possível implantar uma API em mais de um ambiente ao mesmo tempo. Você pode ler mais sobre como fazer o deploy de APIs aqui. |
-
Preserve Query String: se a opção for marcada, a query string presente na requisição será repassada para a API que será chamada internamente.
-
Query: permite a inserção de query string.
-
Preserve Path Param: se a opção for marcada, o path param presente na requisição será repassado para a API que será chamada internamente.
-
Path Param: permite a inserção de path param.
-
Preserve Body: se a opção for marcada, o body contido na requisição será repassado para a API que será chamada internamente. O campo é habilitado quando o método for diferente de GET.
-
Body: permite a inserção de um body. O campo é habilitado quando o método for diferente de GET e o campo Preserve Body estiver desmarcado.
-
Preserve Headers: se marcado, os headers presentes na requisição serão repassados para a API que será chamada internamente.
-
Headers: permite a inserção de headers.
| O header de Transfer-Encoding é removido quando a requisição trafega pelo gateway, tanto em response como em request. Para mais informações sobre a remoção de headers, clique aqui. |
Funcionamento
Para mostrar o funcionamento do Internal API Call, vamos considerar o seguinte caso:
No caso da comunicação interna, já existe uma API exposta que faz o envio da mensagem pelo sistema interno (radio-messages) e agrega as respostas: a LSA Internal Communication. Para aproveitar essa API, já implantada no mesmo ambiente da LSA Communication, utilizamos o Internal API Call.
As imagens a seguir mostram, respectivamente, a sequência dos interceptores no fluxo da API e as configurações utilizadas no Internal API Call:
A LSA Internal Communication retorna, com código de status 200, o seguinte bodyfootnote:
{
"messages": [
{
"message": "I've already joined, Sal, a year ago. Is this just a test message?",
"author": "Eva"
}
]
}Após a chamada, o interceptor irá retornar um objeto do tipo ApiResponse que será armazenado nas variáveis de contexto da chamada.
Para recuperar a resposta, é necessário criar um custom interceptor que acesse $call.contextVariables.get(“Variable Name”).
Abaixo está o código do custom JavaScript interceptor que será usado para capturar a resposta e incluir o body e o status na resposta final:
// Captura a resposta do Internal API Call
var respRadio = $call.contextVariables.get('radioMessages');
// Cria um objeto ApiResponse para essa chamada
$call.response = new com.sensedia.interceptor.externaljar.dto.ApiResponse();
$call.response.addHeader('Content-Type', 'application/json');
// Template JSON para a mensagem retornada
var respBody = JSON.parse('{"radio": {"status": 0, "body": {}}}');
// O status retornado é um Object, não um Number
var statusRadio = respRadio.getStatus();
// O método intValue é chamado para obter um objeto Number
respBody.radio.status = statusRadio.intValue();
// O body é inserido apenas se o status retornado for 200
if (statusRadio == 200){
respBody.radio.body = JSON.parse(respRadio.getBody().getString("UTF-8"));
}
// Injeta o body modificado na ApiResponse
$call.response.getBody().setString(JSON.stringify(respBody), "UTF-8");
// Define o status de retorno como 200
$call.response.setStatus(200);Por fim, o body da resposta da chamada POST ao recurso internal-messages da LSA Communication será:
{
"radio": {
"status": 200,
"body": {
"messages": [
{
"message": "I've already joined, Sal, a year ago. Is this just a test message?",
"author": "Eva"
}
]
}
}
}Share your suggestions with us!
Click here and then [+ Submit idea]