WSO2 es un gigante mundialmente famoso en lo que respecta a middleware de código abierto, cuya API MicroGateway es una solución de gestión de API nativa de la nube y de código abierto a nivel empresarial que está totalmente optimizada para plataformas de microservicios. Lo más destacable de la API MicroGateway es que es amigable con Dev y Dev-Ops, altamente escalable, sin estado, descentralizada, y está desarrollada a partir de Ballerina, que es el último lenguaje de programación nativo de la nube de WSO2. Además, Ballerina también comprende contenedores ligeros junto con tiempos de arranque rápidos, baja huella de memoria y pequeños tamaños de distribución.
Recientemente, WSO2 ha lanzado la última versión de su impresionante MicroGateway que se denomina “WSO2 API MicroGateway 3.0”. La última versión de la API MicroGateway fue publicada con un conjunto de nuevas e impresionantes características, incluyendo la definición de API por endpoints de recursos, soporte HTTP2, autenticación basada en SSL mutuo, autenticación básica basada en la configuración, Global throttling, transformación de petición /respuesta y validación de esquemas, integración con administradores de claves de terceros y mucho más. La arquitectura de la última versión de MicroGateway ha sido actualizada para ser más fácil de utilizar para el desarrollador y también ha sido dividida en Runtime (tiempo de ejecución) y las herramientas para desarrolladores (MicroGateway toolkit). MicroGateway 3.0 estandariza la definición de la API mediante especificaciones de API abiertas, lo que facilita la vida del desarrollador ya que puede colaborar la creación de API y probarlas de forma independiente. Sin duda, esto garantizaría un enfoque prioritario desde el desarrollador, tal y como se introduce en las notas de la versión.
El objetivo principal de esta serie de artículos es guiarle en la instalación (con dependencias), familiarizarle con los cambios de arquitectura y también demostrarle las últimas características lanzadas de la API MicroGateway 3.0 de WSO2. Se incluirá la implementación práctica de diferentes casos de uso para demostrar la última capacidad de MicroGateway, utilizando una simulación de la API de un cliente de una tienda en línea.
1. Guía de instalación
1.1. Java (JDK 1.8)
Java es un lenguaje de programación de propósito general que se utiliza con mayor frecuencia en los servidores backend. Java se utiliza como motor subyacente de tiempo de ejecución para la mayor parte del software de la WSO2, así como para Ballerina y para la API MicroGateway. El JDK 1.8 es la versión más recomendada para Ballerina y MicroGateway. Por favor, descargue e instale su distribución favorita de java compatible con JDK 1.8.
1.2. Ballerina
Por favor, descargue e instale la última versión de Ballerina de la página oficial de WSO2 Ballerina. También puede instalar el plugin IDE en su IDE de preferencia.
Por favor, consulte la guía de instalación de Ballerina para obtener más información.
1.3. API Microgateway de WSO2: Toolkit y Runtime
Como mencionamos anteriormente, el MicroGateway 3.0 de WSO2 ha sido dividido en una distribución que incluye Toolkit y Runtime. Puedes descargar las versiones de la página oficial de la WSO2 y extraer los archivos. Asegúrese de que la carpeta /bin de las instalaciones de MicroGateway Toolkit y Runtime estén en su variable PATH. A continuación, puede ejecutar los comandos “micro-gw” y “gateway” directamente desde el terminal. (Nota: Por favor, asegúrese de que tengan el permiso ejecutable (+x) en los sistemas operativos unix/linux.)
Un archivo .bash_profile de ejemplo para sistemas operativos similares a unix (puede agregar manualmente las carpetas de instalación a la variable PATH de los sistemas operativos Windows)
# microgateway toolkit directory export MGW_TOOLKIT_HOME = /opt/wso2-microgateway-toolkit # microgateway runtime directory export MGW_RUNTIME_HOME = /opt/wso2-microgateway-runtime # adding microgateway components into your PATH export PATH=$PATH:$MGW_TOOLKIT_HOME/bin:$MGW_RUNTIME_HOME/bin
Por favor, consulte la guía de instalación oficial de MicroGateway 3.0 para obtener más información.
Note:
El Runtime de la API MicroGateway de WSO2 puede ser desplegado en muchos patrones diferentes. No obstante, los patrones de implementación de MicroGateway son tema para otro artículo. Por favor, consulte el artículo “Patrones de implementación de la API MicroGateway de WSO2” de Fernando Chanaka para más información sobre implementaciones complejas. Sin embargo, se recomienda realizar una implementación simple para el propósito de este artículo.
02. Crear, construir y ejecutar un proyecto de MicroGateway
2.1. Proyecto Sandbox
El proyecto Sandbox contiene las dependencias y fragmentos de código necesarios para cada escenario del artículo. Puede empezar a trabajar en el directorio “sandbox”. La versión final de cada escenario está en el directorio “complete”. Por favor, copie el proyecto Sandbox desde el repositorio de GitHub en https://github.com/hjchanna/wso2-api-micro-gw3-sandbox
Note:
Puedes usar tu git client o ejecutar los siguientes comandos para clonar el repositorio de git. Por favor, no olvides iniciar el proyecto sandbox.
git clone git@github.com:hjchanna/wso2-api-micro-gw3-sandbox.git
El proyecto Sandbox también contiene la implementación del servicio de atención al cliente de la simulación de la tienda en línea, como se mencionó en las secciones anteriores. La implementación del servicio de atención al cliente contiene los siguientes endpoints de recursos que se utilizarán para demostrar las capacidades de MicroGateway en secciones posteriores.
| Método de petición | Contexto de la API | Descripción |
| GET | /customer | Obtener todos los datos del cliente |
| GET | /customer/{customerId} | Obtener datos de un cliente según una id en particular |
| POST | /customer | Añadir un nuevo cliente |
Por favor, siga los siguientes pasos para iniciar el servicio al cliente de la API.
- Diríjase a la carpeta customer_service del proyecto Sandbox
- Introduzca el siguiente comando para ejecutar el servicio al cliente de Ballerina
ballerina run customer_service.bal
Luego, el servicio de atención al cliente debería haberse iniciado en el puerto 8080 y se puede probar la API del cliente mediante el comando curl. También puede utilizar su herramienta de pruebas de API preferida, por ejemplo: Postman.
# Obtener todos los datos del cliente
curl http://localhost:8080/customer
# Obtener datos de un cliente según una id
curl http://localhost:8080/customer/1
# Añadir un nuevo cliente
curl -X POST http://localhost:8080/customer -d ‘{“id”: “6”, “name”: “Harry James Potter”}’
2.2. Crear un proyecto de MicroGateway
El Toolkit de MicroGateway de WSO2 permite inicializar un proyecto fácilmente con todas las configuraciones requeridas. Ejecute el siguiente comando para generar un nuevo proyecto de MicroGateway.
micro-gw init <your-project-name>
Tras esto, debería haber generado un nuevo proyecto MicroGateway con la siguiente estructura
<your-project-name>/ ├── api_definitions # open API definition files ├── conf # project config │ └── deployment-config.toml ├── extensions │ ├── extension_filter.bal │ ├── startup_extension.bal │ └── token_revocation_extension.bal ├── interceptors # custom interceptors ├── policies.yaml ├── services # gateway specific services │ ├── authorize_endpoint.bal │ ├── revoke_endpoint.bal │ ├── token_endpoint.bal │ └── user_info_endpoint.bal └── target # build output └── gen
Consulte la documentación oficial de WSO2 para obtener más información sobre la estructura de los proyectos de MicroGateway.
Nota:
MicroGateway de WSO2 no puede construir un proyecto satisfactoriamente si éste no contiene definiciones válidas de API abierta. Por favor, copie el archivo customer_api.yaml en la carpeta api_definitions de su proyecto. Podrá encontrar el archivo customer_api.yaml “en la carpeta sandbox projects” del proyecto Sandbox.
2.3. Construir y ejecutar un proyecto de MicroGateway
El Toolkit de MicroGateway de WSO2 también le permite construir un proyecto fácilmente a través de la terminal. Para ello, vaya al directorio principal de su proyecto y ejecute el siguiente comando para construir su proyecto de microgateway.
micro-gw build <your-project-name>
El comando «micro-gw build» traduce los archivos de definición de la API abierta en archivos fuente de Ballerina y los compila en archivos ejecutables de Ballerina. El comando «micro-gatewat build» también genera el Dockerfile y las imágenes, si ya ha configurado el proyecto. El archivo de salida del comando «build» debería estar disponible en la siguiente ubicación después de una compilación exitosa.
<your-project-folder>/target/<your-open-api>.balx
Una vez que haya construido el proyecto MicroGateway, puede ejecutarlo a través del siguiente comando en el Runtime de Microgateway.
gateway <your-project-folder>/target/<project-name>.balx
Tras ello, su proyecto MicroGateway debería haberse iniciado en los números de puerto 9090, 9095 y 9096 por defecto. Los puertos predeterminados de MicroGateway se utilizan de la siguiente manera.
Port 9090 – muestra la API a través el protocolo HTTP
Port 9095 – muestra la API a través del protocolo HTTPS
Port 9096 – API de administración de MicroGateway según el protocolo HTTPS
Nota:
Tenga en cuenta que las siguientes convenciones de proyecto se utilizarán en las secciones posteriores del artículo.
$MGW_TOOLKIT_HOME – directorio de microgateway toolkit
$MGW_RUNTIME_HOME – directorio de microgateway runtime
$PROJECT_HOME – <sandbox project dir>/ directorio sandbox
03. “Autenticación básica” basada en la configuración
El esquema básico de autenticación es un esquema de autorización simple estándar que utiliza condificación base64 mediante nombre de usuario y contraseña. Como novedad, WSO2 MicroGateway permite a las APIs identificar a los usuarios a través de un esquema básico de autenticación tanto en el nivel de API como en el nivel de recursos. La siguiente guía paso a paso le orientará a través de la configuración de nivel de API y de nivel de recursos. Puede probar la autenticación básica en el nivel de API (sección A) o en el nivel de recursos (sección B) o en ambos por separado.
3.A. Definición de la autenticación básica en la API abierta (nivel de API)
- Siga los pasos anteriores para inicializar un nuevo proyecto de MicroGateway con el nombre basic_auth_sample y copie el archivo de definición de API abierta de muestra (el archivo customer_api.yaml provisto en el proyecto Sandboz) en la carpeta api_definition de su proyecto.
- Añada la siguiente configuración básica de autenticación al archivo online_store.yaml recién creada.
# enable the basic authentication scheme for the API security: - online_store_basic_auth: [] # define the basic authentication scheme components: securitySchemes: online_store_basic_auth: type: http scheme: basic
3.B. Definición de la autenticación básica en la API abierta (nivel de recurso)
- Inicialice un nuevo proyecto de MicroGateway con el nombre basic_auth_sample y copie el archivo de definición de la API abierta customer_api.yaml en la carpeta api_definition de su proyecto.
- Añada la configuración básica de autenticación a cada recurso del archivo customer_api.yaml recién creado.
- Agregue una sección de seguridad a cada recurso de la siguiente manera
... "/customer": get: responses: "200": description: ok, get all customer data security: - online_store_basic_auth: [] ...
- Defina el esquema básico de autenticación en la sección “components”
securitySchemes: online_store_basic_auth: type: http scheme: basic
3.2. Configuración de MicroGateway para la autenticación básica
- Abra el archivo de configuración de MicroGateway
($MGW_RUNTIME_HOME/conf/micro-gw.conf) en su editor de preferencia - Localice la sección [b7a.users] y añada la siguiente configuración básica de autenticación
[“b7a.users”]
[“b7a.users.<username>”]
password=”<SHA1 hash password>”
Ejemplo: Nombre de usuario: admin, Contraseña: password
[“b7a.users”]
[“b7a.users.admin”]
password=”5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8″
Nota:
La contraseña debe ser valores de código cifrado SHA1 en mayúsculas. Puede utilizar una herramienta en línea para generar el hash o generarlo a través de la terminal mediante el siguiente comando.
echo -n “<password>” | openssl sha1 | tr ‘a-z’ ‘A-Z’
3.3. Crear, ejecutar y probar el proyecto
- Utilice el Toolkit de MicroGateway para construir el proyecto basic_auth_sample como se menciona en la sección “Antes de empezar” (micro-gw build basic_auth_sample). Una vez terminada la compilación, debería haberse generado el archivo customer_api.balx en el directorio de destino del proyecto.
- Inicie MicroGateway con el archivo customer_api.balx recién creado.
gateway $PROJECT_HOME/basic_auth_sample/target/customer_api.balx
El MicroGateway de WSO2 se iniciará en los puertos 9090, 9095 y 9096, y luego deberemos probar la API. - En el archivo micro-gw.conf se configuraron las credenciales básicas de autenticación como “admin” y “password”. De acuerdo con el esquema básico de autenticación, el encabezado “Authorization” debe ser un nombre de usuario cifrado en base64, y debe estar separado de la contraseña por dos puntos. Genere un código en base64 para la cadena “admin:password” a través del terminal.
echo “admin:password” | base64 - Utilice el comando curl o su herramienta de prueba de API favorita para probar la API
curl -X GET \
http://localhost:9090/api/v1/customer \
-H ‘Authorization: Basic YWRtaW46cGFzc3dvcmQ=’
Y también puede acceder el endpoint HTTPS y usar el comando curl de la siguiente manera para probar los puntos finales HTTPS. (Nota: La seguridad HTTPS será ignorada en esta etapa ya que los certificados no están configurados correctamente).
curl -kX GET \
http://localhost:9095/api/v1/customer \
-H ‘Authorization: Basic YWRtaW46cGFzc3dvcmQ=’
04. Validación de esquemas de Petición y Respuesta
MicroGateway de WSO2 permite configurar la validación de esquemas de petición y respuesta a través de la definición de la API abierta. Se requiere simplemente definir el esquema de petición o respuesta en la API abierta y habilitar la validación del esquema a través de la configuración del Runtime de MicroGateway.
4.1. Configuración de la API abierta para la validación de esquemas de petición/respuesta
Siga los pasos que se indican a continuación para probar la validación del esquema de un proyecto de MicroGateway de WSO2.
- Inicialice un nuevo proyecto de MicroGateway a través del Toolkit de MicroGateway con el nombre “request_response_validation”. Y copie el archivo customer_api.yaml en la carpeta api_definitions del proyecto.
- Configure la API request_response_validation para que pueda autorizar a través del esquema de autenticación básico tal y como se menciona en la sección anterior.
- Añada el esquema de cliente a la sección “components” del archivo de definición de la API abierta (customer_api.yaml)
components: ... schemas: customerSchema: type: object required: - id - name properties: id: type: integer name: type: string
- Defina el cuerpo de la petición de API abierta para el endpoint POST /customer en la sección “components” del archivo de definición de la API abierta y enlace con el endpoint correspondiente.
components: ... requestBodies: customerBody: content: application/json: schema: $ref: '#/components/schemas/customerSchema' required: true
Una vez que haya definido el cuerpo de la petición para el endpoint POST /customer, es necesario enlazarlo con la definición del endpoint correspondiente. Añada las siguientes líneas en la sección “post” del endpoiint /customer como se indica a continuación.
post: ... requestBody: $ref: '#/components/requestBodies/customerBody'
Debería haber configurado con éxito la validación del esquema para el cuerpo de la petición del endpoint POST /customer. Puede saltar a la sección de prueba (test) o continuar en la siguiente sección de configuración de validación de esquemas de los endpoints GET /customer/{customerId} y GET /customer.
- Puesto que el esquema de cliente (customer) ya se ha definido en el paso anterior, es posible enlazarlo directamente con la respuesta GET /customer/{customerId}. Añada la siguiente configuración en la sección de respuesta “200” del endpoint correspondiente.
'200': ... content: application/json: schema: $ref: '#/components/schemas/customerSchema'
- Una respuesta exitosa del endpoint GET /customer devolverá un array de ítems de cliente en formato json. Por lo tanto, es necesario definir el esquema de respuesta como un array de ítems de cliente. Añada las siguientes configuraciones al endpoint GET /customer para definir el esquema de respuesta.
get: ... responses: '200': ... content: application/json: schema: type: array items: $ref: '#/components/schemas/customerSchema'
- También es posible validar las variables de ruta y los parámetros de consulta de una petición utilizando MicroGateway. En este ejemplo, consideraremos la validación de la solicitud del endpoint GET /customer/{customerId}. El objetivo es que el customerId sea una variable de ruta entera, lo cual se puede definir de la siguiente manera.
get: ... parameters: - in: path name: customerId required: true schema: type: integer format: int32
4.2. Configuración de Runtime de MicroGateway
Es posible que necesite habilitar la validación de esquemas de petición y respuesta en el Runtime de MicroGateway. Por favor, abra el archivo de configuración de MicroGateway y busque la sección “[validationConfig]”. Actualice los valores enableRequestValidation y enableResponseValidation como se indica a continuación.
[validationConfig]
enableRequestValidation = true
enableResponseValidation = true
4.3. Crear, ejecutar y probar el proyecto
- Construya un proyecto usando el Toolkit de MicroGateway de la siguiente manera (Por favor refiérase a la sección “Construir, ejecutar y probar” del ejemplo anterior para obtener información más detallada)
micro-gw build request_response_validation
- Inicie MicroGateway con el archivo ejecutable Ballerina recién generado
gateway \
$PROJECT_HOME/target/request_response_validation.balx
MicroGateway debería haberse iniciado en los puertos predeterminados. Continúe con el siguiente paso para probar cada escenario del caso de uso.
- Pruebe cada escenario de validación de esquemas modificando los valores de los parámetros de petición y el cuerpo de la petición.
- solicitar la validación de parámetros del endpoint GET /customer/{customerId}.
curl -X GET \
http://localhost:9090/api/v1/customer/{integer-customer-id} \
-H ‘Authorization: Basic YWRtaW46cGFzc3dvcmQ=’
- solicitar la validación del cuerpo de la petición para el esquema de cliente (customer)
curl -X POST \
http://localhost:9090/api/v1/customer \
-H ‘Authorization: Basic YWRtaW46cGFzc3dvcmQ=’ \
-d ‘{“id”:1,”name”: “Harry James Potter”}’
05. Transformación de peticiones y respuestas
La API MicroGateways de la WSO2 permite el patrón de interceptores que es compatible con la ampliación de la funcionalidad de MicroGateways. Los interceptores MicroGateway se definirán como funciones de Ballerina, y son capaces de realizar mediaciones y transformaciones. Hay dos tipos de interceptores disponibles en MicroGateway: interceptores de petición e interceptores de respuesta. Los interceptores de petición se activan antes de enviar la solicitud al servicio backend, mientras que los interceptores de respuesta se activan antes de enviar la respuesta a la API cliente.
Como se mencionó anteriormente, los interceptores deben definirse en el lenguaje Ballerina, y los respectivos archivos de Ballerina deben colocarse en el directorio de interceptores de un proyecto de MicroGateway. Además, los interceptores deben estar vinculados a la API en el archivo de definición de la API abierta, ya sea a nivel de API o a nivel de recursos, a través de las extensiones de la API abierta específicas de WSO2, como se indica a continuación.
#request interceptor
x-wso2-request-interceptor: <your-request-interceptor>
#response interceptor
X-wso2-response-interceptor: <your-response-interceptor>
5.1. Ejemplo de interceptor de petición
Según la API de cliente del proyecto Sandbox, el endpoint POST /customer se utilizará para añadir un nuevo cliente. Sin embargo, el cuerpo de la petición tiene que tener definido el identificador de cliente, el cual no puede ser predicho por los clientes. Además, el identificador de cliente debe ser difícil de mantener en un orden secuencial. En este caso de uso, le guiaremos a través de la generación automatizada del identificador de cliente y convertiremos la payload de la petición en un formato compatible con el servicio backend.
- Inicialice un nuevo proyecto de MicroGateway y copie las definiciones de API abiertas en el proyecto. El nombre sería “request_response_transformation”.
- Configure este proyecto MicroGateway para habilitar el esquema de autenticación básico.
- Cree un nuevo archivo Ballerina con el nombre “transform_post_request.bal” en el directorio de interceptores del proyecto de MicroGateway y copie el siguiente código de Ballerina en el archivo transform_post_request.bal
import ballerina/log;
import ballerina/http;
//customer API client
http:Client httpClient = new("http://localhost:8080");
public function transformPostRequest (http:Caller outboundEp, http:Request req) {
//get all customers to calculate next customer id
var response = httpClient->get("/customer");
var id = -1;
if (response is http:Response) {
json | error customers = response.getJsonPayload();
if (customers is json) {
//calculate next customer id
id = customers.length() + 1;
}
}
log:printInfo("Generated a new id for the customer :" + id);
//set the calculated customer id to the request payload
var requestPayload = req.getJsonPayload();
if (requestPayload is json) {
requestPayload.id = id;
req.setJsonPayload(untaint requestPayload, contentType = "application/json");
}
}
El código de Ballerina de arriba interactuará con el endpoint GET /customer del backend de atención al cliente para obtener todos los clientes. Y generará el identificador de cliente añadiendo un número entero al número de clientes devueltos. Después, añadirá o actualizará el identificador de cliente en el cuerpo de la solicitud y lo pasará al backend.
Nota:
No se recomienda realmente llamar al servicio backend pasando por alto el gateway de la API. Se ha implementa de esa manera sólo con fines de demostración.
- Enlace el interceptor de peticiones al recurso correspondiente del archivo de definición de la API utilizando la extensión de la API abierta específica de WSO2 de la siguiente manera. Luego, todo estará listo para construir y probar el proyecto.
post:
…
x-wso2-request-interceptor: transformPostRequest
5.2. Ejemplo de Interceptor de respuesta
Puede que haya notado que el servicio backend del cliente devuelve un mensaje de error en formato json cuando detecta un error. Por ejemplo, el endpoint GET /customer/{customerId} devolverá la siguiente respuesta si no hay un cliente disponible para el identificador de cliente proporcionado.
{
“message” : ”Customer not found for id: <customer-id>”
}
Esta sección le guiará a través de la transformación de dichas respuestas en el formato estándar de mensajes de error de la API MicroGateway con el siguiente formato.
{
"fault": {
"code": 900000,
"message": "Customer not found for the id: <customer-id>",
"description": "An error returned from the customer backend"
}
}
Continuemos implementando un nuevo interceptor de respuesta de Ballerina sobre el proyecto request_response_transformation.
- Cree un nuevo archivo de Ballerina con el nombre “transform_message_response.bal” en la carpeta de interceptores del proyecto. Y añada el siguiente código Ballerina en el archivo.
import ballerina/http;
public function transformMessageResponse (http:Caller inboundEp, http:Response res) {
//get and check the response code from the backend
int statusCode = res.statusCode;
if (404 == statusCode || 500 == statusCode) {
//create a new json response payload to return to the client
json responsePayload = {
};
json | error backendPayload = res.getJsonPayload();
//transform the payload into the required format
if (backendPayload is json) {
responsePayload.fault = {};
responsePayload.fault.code = 900000;
responsePayload.fault.message = backendPayload.message;
responsePayload.fault.description = "An error returned from the customer backend";
//set the response payload
res.setJsonPayload(untaint responsePayload, contentType = "application/json");
}
}
}
El código de Ballerina anterior comprobará el código de respuesta devuelto por el servicio backend y transformará la payload de respuesta en el formato requerido si el código de respuesta es igual a 404 o 500.
- Enlace el interceptor de respuesta en la definición de API abierta en el nivel de API que se aplicará a todas las respuestas de la siguiente manera.
#add following line into the root level of the open API def
x-wso2-response-interceptor: transformMessageResponse
5.3. Crear, ejecutar y probar el proyecto
- Construya el proyecto usando el Toolkit de MicroGateway de la siguiente manera (Por favor refiérase a la sección “construir, ejecutar y probar” del ejemplo de autenticación básica para obtener información más detallada)
micro-gw build request_response_transformation
- Inicie MicroGateway con el archivo ejecutable Ballerina recién generado
gateway \
$PROJECT_HOME/target/request_response_tranformation.balx
MicroGateway debería haberse iniciado en los puertos predeterminados. Continúe con el siguiente paso para probar cada escenario del caso de uso.
- Pruebe el endpoint de añadir un nuevo cliente sin ningún identificador de cliente en el cuerpo de la petición. El identificador del cliente debería ser generado automáticamente por el propio interceptor de MicroGateway.
curl -X POST \
http://localhost:9090/api/v1/customer \
-H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ=' \
-d '{"name": "Harry James Potter"}'
Una vez que la petición anterior se haya completado con éxito, llame al endpoint de GET /customer para verificar el resultado.
curl -X GET \ http://localhost:9090/api/v1/customer \ -H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ='
Verifique que el cliente recién agregado esté en el backend con el identificador de cliente disponible.
- Pruebe el endpoint GET /customer/{customerId} para buscar un identificador de cliente que no existen. Debería devolver un mensaje de error con el formato de error esperado.
curl -X GET \
http://localhost:9090/api/v1/customer/100 \
-H ‘Authorization: Basic YWRtaW46cGFzc3dvcmQ=’
Resumen
Espero que este artículo le ayude a tener una idea básica de la API MicroGateway 3.0 de WSO2, incluyendo la instalación y la arquitectura más reciente. También espero que se anime a probar las nuevas características introducidas en la última versión. He demostrado algunas de las nuevas características de MicroGateway en una implementación muy sencilla del Runtime. Hay muchas más características para presentarle, incluyendo la configuración del Administrador de claves, el Global Throttle, la configuración SSL, el soporte HTTP/2, las implementaciones de Docker/Kubernetes, la detección de servicios en Runtime y la composición de múltiples microservicios, lo que requiere una implementación más compleja de MicroGateway para demostrarlo. Para evitar que este artículo se haga más largo y complicado, dejaré la explicación de tales casos de uso para las próximas entregas de esta serie.
Espero que haya disfrutado de la primera entrega de la serie de artículos. No olviden dejar sus comentarios. Por favor, contácteme si tiene alguna duda sobre la API MicroGateway de WSO2. Estaré encantado de responder a cualquier pregunta.
