Internal API Call
Internal API Call permite a los usuarios invocar una llamada interna basada en la configuración definida.
Imagine que, para una API determinada llamada «SearchSalesInformation», usted necesita que la petición se someta a una simple autenticación de inicio de sesión con contraseña. En este escenario, usted ya tiene una API para este tipo de autenticación, denominada «AuthenticateUser», que ya está registrada. Puesto que ya tiene una API expuesta («SearchSalesInformation»), así como una API que realiza el control de autenticación («AuthenticateUser»), no es necesario replicar la lógica de autenticación en el flujo de la primera API. En su lugar, puede agregar el interceptor API Internal Call en el flujo de la API «SearchSalesInformation», redireccionando las peticiones a «AuthenticateUser». En función de lo que devuelva el proceso de autenticación, el interceptor decidirá si continuar o anular el proceso. |
Configuración del interceptor
Para configurar este interceptor, basta arrastrarlo al flujo de llamada y rellenar los campos con la información deseada, como se muestra en la imagen abajo.
No es posible utilizar este interceptor en el flujo de respuesta, sólo en el de llamada. |
-
Variable Name: define el nombre de la llamada interna, única por flujo. La respuesta a la llamada se recupera dentro del mapa
$call.contextVariables
utilizando el nombre informado aquí. Se requiere un custom interceptor para esto, como se muestra abajo. -
API: API que se va a invocar.
-
Revision: revisión de la API que se va a invocar.
-
Resource: recurso que se va a invocar.
-
Operation: operación a realizar.
Sólo puede invocar una API que esté desplegada en el mismo entorno que la API en cuyo flujo está añadiendo el interceptor. Si pensamos en las APIs en el ejemplo de uso anterior, para llamar a la API «AuthenticateUser», ella debe ser desplegada en el mismo entorno que la API «SearchSalesInformation», que es la API que contiene el interceptor Internal API Call. Si quiere invocar una API que no está desplegada en el mismo entorno, es necesario realizar el deploy. Recuerde que es posible desplegar una API en más de un entorno al mismo tiempo. Puede leer más sobre cómo hacer el deploy de APIs aquí. |
-
Preserve Query String: si está marcada, la cadena de consulta presente en la petición se transferirá a la API invocada internamente.
-
Query: permite la inserción de una cadena de consulta.
-
Preserve Path Param: si está marcada, el parámetro de ruta (path param) presente en la solicitud se transferirá a la API invocada internamente.
-
Path Param: permite la inserción de un parámetro de ruta.
-
Preserve Body: si está marcada, el cuerpo contenido en la petición se transferirá a la API invocada internamente. Este campo se habilita cuando el método es diferente de GET.
-
Body: permite la inserción de un cuerpo. El campo se habilita cuando el método es diferente de GET y el campo Preserve Body está desactivado.
-
Preserve Headers: si está marcada, los headers presentes en la petición se transferirán a la API invocada internamente.
-
Headers: permite la inserción de headers.
El header de Transfer-Encoding es removido quando la solicitud viaja a través del gateway, tanto en response como en request. Para obtener más información sobre la eliminación de headers, haga clic aquí. |
Funcionamiento
Para mostrar cómo funciona el Internal API Call, consideremos el siguiente caso:
En el caso de la comunicación interna, ya existe una API expuesta que envía el mensaje a través del sistema interno (radio-messages) y agrega las respuestas: LSA Internal Communication. Para aprovechar esta API, ya desplegada en el mismo entorno que la LSA Communication, utilizamos el Internal API Call.
Las siguientes imágenes muestran, respectivamente, la secuencia de interceptores en el flujo de la API y la configuración utilizada en el Internal API Call:
LSA Internal Communication devuelve, con el código de estado 200, el siguiente cuerpofootnote:
{
"messages": [
{
"message": "I've already joined, Sal, a year ago. Is this just a test message?",
"author": "Eva"
}
]
}
Tras la llamada, el interceptor devolverá un objeto de tipo ApiResponse que se almacenará en las variables del contexto de la llamada.
Para recuperar la respuesta, es necesario crear un custom interceptor que acceda a $call.contextVariables.get(“Variable Name”)
.
A continuación se muestra el código para el custom JavaScript interceptor que se utilizará para capturar la respuesta e incluir el cuerpo y el estado en la respuesta final:
// Captura la respuesta de Internal API Call
var respRadio = $call.contextVariables.get('radioMessages');
// Crea un objeto ApiResponse para esta llamada
$call.response = new com.sensedia.interceptor.externaljar.dto.ApiResponse();
$call.response.addHeader('Content-Type', 'application/json');
// Plantilla JSON para el mensaje devuelto
var respBody = JSON.parse('{"radio": {"status": 0, "body": {}}}');
// El estado devuelto es Object, no Number
var statusRadio = respRadio.getStatus();
// Se llama al método intValue para obtener un objeto Number
respBody.radio.status = statusRadio.intValue();
// Se inserta un cuerpo sólo si se devuelve un estado 200
if (statusRadio == 200){
respBody.radio.body = JSON.parse(respRadio.getBody().getString("UTF-8"));
}
// Inserta el cuerpo modificado en el ApiResponse
$call.response.getBody().setString(JSON.stringify(respBody), "UTF-8");
// Establece el estado de retorno como 200
$call.response.setStatus(200);
Finalmente, el cuerpo de la respuesta de la llamada POST al recurso internal-messages de 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]