From zero to hero con Mulesoft y su Mocking Service

¿Qué es un Mock API?

Si has llegado hasta aquí, seguramente ya estés familiarizado con el concepto de Mock API. Pero por si acaso, vamos a explicarlo brevemente. Tan breve, que simplemente vamos a decir que un Mock API va a ser un API que nos provee de datos dummy para simular las peticiones a las mismas. Por extensión, el Mock Service de Mulesoft no será más que el servicio que la plataforma nos ofrece para crear estos mocks.

¿Por qué necesito un Mock API?

Nos podemos encontrar en multitud de situaciones que conviertan el consumo de un API en algo duro e incluso frustrante en nuestra etapa de desarrollo: autenticaciones, limitaciones, incluso cambios en la especificaciones o errores en las propias APIs si es que se están desarrollando a la vez que nuestro consumidor,...

Las Mock API imitarán el comportamiento de las APIs reales, devolviendo datos de prueba o datos esperados,

Esto nos va a permitir que cuando estemos desarrollando un consumidor de este API (nuestra web, aplicación móvil o lo que sea) podré comprobar que mi consumidor está bien diseñado, abstrayéndonos de posibles errores o falta de datos en la propia API.

Pero no solo para realizar estas pruebas será útil este Mock API, sino que en típicos casos donde dos equipos, o partes del mismo, están trabajando en paralelo, típicamente con uno centrado en el front-end y otro en el back-end, usar este tipo de Mocks romperá las dependencias entre ellos. El equipo de front-end no tendrá que quedarse esperando a que el equipo de back-end termine de desarrollar, desplegar, probar,... el API, sino que con una especificación bien diseñada, documentada y con los datos necesarios, ambos equipos podrán empezar a trabajar de forma paralela. Aquí cobra mucha importancia el disponer de nuestro contrato, que será nuestra especificación.

Y aún tenemos una ventaja más del uso de estas Mocks APIs. En un ciclo de vida, donde el diseño del API puede ser algo iterativo, tener esta capacidad nos permite poder tener feeback tremendamente rápido bien sea de un área de negocio o de un área técnica. Por si no te está sonando a algo, las Mocks API nos puedan ayudar y mucho a tener un enfoque API First.

¿Qué nos ofrece Mulesoft?

Mulesoft, con su plataforma Anypoint, trata de ofrecernos todas las herramientas que podemos necesitar en lo que respecta a Integración, y ahí las APIs y por ende las Mock API tienen mucho peso.

De hecho, cuando empezamos a trabajar con la plataforma, rápidamente nos damos cuenta que su Mock Service es una de las herramientas más potentes que Mulesoft ofrece, sobre todo por su simplicidad: con una especificación correcta y un par de clicks, podemos ofrecer una Mock API totalmente funcional que puede ser consumida.

Esto no habilita solo la capacidad de que los consumidores puedan empezar su trabajo, sino que en un ciclo de vida donde necesitaremos del feedback de otras áreas, podremos empezar a trabajar con ellas, iterando el diseño de la especificación y la solución, sin tener que tirar una sola línea de código. Y de paso dicho, sin la necesidad de desplegar artefacto alguno en ningún servidor.

Pensando en el ciclo de vida de APIs que Mulesof propone, estamos hablado de que estas Mock APIs va a ayudarnos a acelerar especialmente la parte de prototipado, donde podremos, como hemos dicho, iterar sobre el diseño de nuestras APIs.

¿Cómo creo mi primer Mock API?

Puede que estemos hablando de una funcionalidades más potentes de Mulesoft. En esta plataforma, crear un mock es tan sencillo como crear la especificación de un API. Desde ese momento, tendremos habilitado un Mock Service con tan solo activar un botón, que expondrá las respuestas que nosotros mismos hayamos puesto como ejemplos.

¿Cómo consumo mi Mock API?

En realidad, es tremendamente sencillo. Una vez activado el Mock Service, tan solo tendremos que copiar el link que nos da y usarlo como dirección de nuestro API, añadiendo el enpoint con los parámetros y cabeceras que necesitemos:

Fácil, sencillo y para toda la familia.

¿Y ahora qué?

Hasta aquí, todo muy bien, pero es donde se complica.

Cuando ponemos varios ejemplos como posibles respuesta en un método, como lo hacemos aquí:

/{id}:
    get:
      description: This is the People API
      responses:
        200:
          body:
            application/json:
              examples:
                1:
                  id: 1
                  name: Luke Skywalker
                  height: 172
                  mass: 77
                  hair_color: blond
                  skin_color: fair
                  eye_color: blue
                  birth_year: 19BBY
                  gender: male
                2:
                  id: 2
                  name: Darth Vader
                  height: 202
                  mass: 136
                  hair_color: none
                  skin_color: white
                  eye_color: yellow
                  birth_year: 41.9BBY
                  gender: male

Cuando hacemos las peticiones al Mock Service, no tenemos control sobre qué valor nos va a devolver.

No lo tenemos? Evidentemente, si estamos aquí es porque efectivamente, Mulesoft nos da las herramientas para obtener lo que queremos.

Cómo forzar el valor devuelto

Si os fijáis, los ejemplos que hemos usado están etiquetados con un número, que hemos hecho coincidir con el id de nuestra entidad. Es este valor el que vamos a usar en una cabecera que Mulesoft nos propociona para indicar lo que queremos que nos devuelva:

MS2-Example

Si os dais cuenta, el valor del id que mandamos en la petición es el mismo en ambos casos. Para hacer estas pruebas estoy usando postman, y podríamos hacer este pequeño juego con variables para asegurarnos que es valor es el mismo tanto en la url como en la cabecera

Si mandamos un valor que no hemos etiquetado, tendremos un bonito error.

Y no, lo siento, no podemos dar formato a ese error.

¿No podemos? Nuevamente tenemos una herramienta para esto.

Cómo forzar errores.

Al igual que ocurre con las respuestas de éxito, podemos indicar que queremos que nuestra petición nos lance un error. Será en la definición del error donde haremos el mismo juego que antes, con el etiquetado de ejemplos.

400:
          body:
            application/json:
              examples:
                1:
                  error: The error 400 for 1 
                2:
                  error: The error 400 for 2 
        401:
          body:
            application/json:
              examples:
                1:
                  error: The error 401 for 1 
                2:
                  error: The error 401 for 2

Si os fijáis estamos pareando los errores con los datos, porque podemos llegar incluso a decir el error que queremos para la petición de qué valor. Esto lo haremos nuevamente mediante el uso de una cabecera:

MS2-Status-Code

Como vemos, con estas dos simples cabecera podemos simular comportamientos que nos pueden ser tremendamente útiles a la hora de desarrollar el consumidor del API, mucho antes de que el propio servicio esté desarrollado. Está claro que tenemos que juguetear con estas cabeceras, pero con un poco de inventiva, podemos lograr mucho.

¿Hay más?

Mulesoft nos proporciona más herramientas en forma de cabeceras para poder simular comportamientos en nuestras APIs que pueden ser muy útiles, pero que para no alargar más este artículo, simplemente mencionaremos:

  • MS2-Delay: Nos permite indicar el número de milisegundos que queremos que nuestra respuesta tarde. Muy útil para simular latencias de red y cargas elevadas en el servidor.

  • MS2-Randomize: si establecemos su valor a true, el servicio genera automáticamente una respuesta si es que no hubiera ejemplo, con valor random basados en los tipos de los atributos.

  • MS2-Strict-Model-Validation: Con valores de true o false, nos permite indicar si queremos que se valide la especificación, pudiendo usar el servicio o no si existieran fallos.

  • MS2-Status-Code-Selection: nos va a permitir modificar el comportamiento por defecto del servicio en cuanto a los código de respuesta.

    • Útil combinado con la cabecera MS2-Error-Level.

    • Puede valer:

      • FIRST: independientemente del orden de los códigos definido, se usará el más bajo.

      • RANDOM: se devolverá un código aleatorio entre los definidos

  • MS2-Error-Rate: Muy útil, indica la probabilidad que queremos tener de obtener un código de estado de error como respuesta. Será un valor entre 0 y 1. Combinable con las siguientes cabeceras.

  • MS2-Error-Level: limitará el rango de códigos de error que se pueden devolver:

    • REQUEST_ONLY: Solo los códigos 4XX.

    • SERVER_ONLY: Solo códigos 5XX.

    • ALL: El servicio de imitación puede utilizar tanto los códigos 4XX como los 5XX. Este es el valor por defecto.

Hemos visto varias maneras de jugar un poco con los servicios Mock que Mulesoft nos proporciona, simulando diferentes comportamientos. Nunca será exactamente lo mismo que tener un API live funcionando, pero nos va a permitir tener un escenario listo para descubir cómo funciona el API en líneas generales y empezar a desarrollar nuestro consumidor.

Pero no te limites a leer esto. Crear tu propia especificación, añade tus ejemplos, activa tu mock, abre tu cliente REST favorito, y a jugar!

Otros

Mulesoft no tiene la exclusiva de crear Mocks API. Existen muchas otras herramientas en el mercado capaces de crear Mocks y Sandbox, con mayor o menor dificultad, tanto para ser ejecutadas en entornos locales como para desplegar en servidores. Algunas pueden ser:

Referencias