api-microgateway-3.0
WSO2

Novedades de WSO2 API Microgateway 3.0

2nd septiembre 2019

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.

 

Nota:

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.

 

-Quizá te interese: Cómo lograr una arquitectura de datos descentralizada con microservicios

 

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

 

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.

 

  1. Diríjase a la carpeta customer_service del proyecto Sandbox
  2. 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)

  1. 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.
  2. Añada la siguiente configuración básica de autenticación al archivo online_store.yaml recién creado

 

# 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

 

-Te podría interesar: DevOps y API strategy: Combinación ganadora

 

3.B. Definición de la autenticación básica en la API abierta (nivel de recurso)

  1. 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.
  2. 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”

components:

securitySchemes:

online_store_basic_auth:

type: http

scheme: basic

 

3.2. Configuración de MicroGateway para la autenticación básica

  1. Abra el archivo de configuración de MicroGateway
    ($MGW_RUNTIME_HOME/conf/micro-gw.conf) en su editor de preferencia
  2. 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

  1. 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.
  2. 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.
  3. 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
  4. 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.

  1. 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.
  2. 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.
  3. 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

  1. 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.

  1. 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’

  1. 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’

 

  1. 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

  1. 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

 

  1. 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.

  1. 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»}’

 

-Échale un vistazo: Domina la transformación de mensajes con WSO2

 

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.

 

  1. Inicialice un nuevo proyecto de MicroGateway y copie las definiciones de API abiertas en el proyecto. El nombre sería «request_response_transformation».
  2. Configure este proyecto MicroGateway para habilitar el esquema de autenticación básico.
  3. 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.

  1. 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>”

}

 

En esta sección, explicaremos cómo convertir dichas respuestas al formato de mensaje de error estándar 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.

 

  1. 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.

 

  1. 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

  1. 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

  1. 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.

  1. 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.

  1. 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.

 

Channa Jayamuni

Ingeniero encargado – Asesoramiento de Chakray

channa@chakray.com