API Mocks rápidos con Postman

En un anterior artículo, estuvimos hablando de cómo hacernos unos auténticos héroes en el uso de los mocks que Mulesoft nos ofrece.

Pero no solo de Mulesoft vive el hombre, y el uso de APIs Mocks no es algo exclusivo de esta plataforma. Hoy veremos como Postman, uno de las aplicaciones más usadas en el mundo como cliente REST. De hecho, Postman se autodenomina una plataforma completa para construir APIs, y es aquí donde empezaremos a ahondar, no solo en cómo consumir APIs, sino cómo nos ayuda para crear unos mocks rápidos.

No vamos a incidir en las ventajas que trabajar con APIs Mocks nos ofrece, sino que iremos directamente a la parte práctica y cómo habilitarnos rápidamente.

Evidentemente, empezaremos por el principio, abriendo la herramienta y comenzando por donde comenzamos siempre, con un “New”, y sí, con un nuevo “Mock Service”.

En este caso vamos a empezar desde 0, con una nueva colección y trataremos de guiarnos por el mismo mock que creamos en el otro artículo. De momento, vamos a simular un simple endpoint y con una respuesta simple.

ENDPOINT

GET /people/1

RESPONSE:

{
    "id": 1,
    "name": "Luke Skywalker",
    "height": 172,
    "mass": 77,
    "hair_color": "blond",
    "skin_color": "fair",
    "eye_color": "blue",
    "birth_year": "19BBY",
    "gender": "male"
}

Sorprendentemente, tras dar a siguiente y una pequeña configuración, tendremos disponible el mock de nuestro servicio:

  • Le daremos el nombre a la colección que queremos crear. En nuestro caso: Postman SW Mock

  • ‘Save the mock server as an environment variable’ lo que hará será crear una url para nuestro mock, que guardará en el entorno que le indiquemos, o nos creará uno nuevo en caso de no seleccionar ninguno. Nosotros no seleccionaremos ninguno.

  • No seleccionaremos ‘Mack mock server private’ por el momento. Esto protegería el mock mediante una APIKey para que no pudiera ser llamado por cualquiera.

  • Marcar ‘Simulate fixed network delay’ nos permitiría simular tiempos de respuesta propios de conexiones 3g(100 ms), 2G(300 ms) o nuestros propios valores. De momento, lo dejamos sin marcar.

Aunque no lo creáis, solo con esto, ya tendríamos habilitado nuestro servicio mock. Postman nos va a crear una colección, con una llamada al endpoint que hemos creado y un archivo de entorno donde nos almacenará la url de nuestro mock. Y adelante, ya podemos hacer nuestras llamadas.

Podríamos usar un archivo de entorno que ya tuviéramos existente si así lo quisiéramos. De hecho, el uso de archivos de entornos es una prácticamente tremendamente recomendada, que nos permite agrupar valores y gestionar su acceso. Esto es muy útil para cuando trabajas en equipo y quieres compartir los mismos valores y para poder gestionar distintos conjuntos de valores para distintos entornos. En nuestro caso, podríamos tener un archivo de entorno para nuestros mocks y otro distinto para cuando tengamos la implementación real, con el mismo conjunto de variables, pero distintos valores.

Fácil, ¿verdad?

Estupendo. Pero esto no siempre es estático. ¿Y si quiero modificar mi respuesta? La verdad es que es bastante sencillo, ya que, al crear la colección, colgando de la petición, tendremos dónde modificar estos valores e incluso añadir cosas como las cabeceras que queremos en nuestra respuesta. Esto nos permite mockear el flujo completo de request and response, donde no solo nos importan los body de las peticiones o las respuestas, sino también los valores de las cabeceras y, cómo no, el valor de los códigos de respuesta.

Tras ello podremos ver cómo nuestra respuesta cambia, tanto en su contenido como en la cabeceras. De hecho, al añadir la cabecera, veremos cómo Postman ya nos reconoce la respuesta como un json y nos lo formatea como tal.

Incluso Postman nos va a habilitar una pequeña sección para tener cierto nivel de logs de las llamadas que hacemos a nuestro mock server.

Disponer de monitorización en nuestras API siempre va a ser una clave de éxito en su uso. Disponer de log y lograr hacer una trazabilidad correcta nos va a ahorrar muchos dolores de cabeza. Y en el caso de estos mocks, no es distinto.

A partir de aquí, podemos empezar a jugar todo lo que queramos.

Por ejemplo, podemos crear varios juegos de datos, para convertir nuestro people/1 en un people/id, donde en función del id que demos a nuestra petición, tengamos un resultado u otro.

A la hora de crear los mocks, podremos jugar no solo con los endpoint en sí y las respuestas, sino con cosas como cabeceras, códigos de error y, si queremos, simular distintos comportamientos para distintos body:

De esta manera, completando nuestras peticiones en la colección, con distintos juegos de datos, podemos lograr tener una mock collection compelta.

Con las capacidades que Postman nos ofrece, tenemos una manera tremendamente sencilla y rápida de empezar a simular llamadas a un API, de manera que no tenemos que esperar a un desarrollo, despliegue y pruebas, pudiendo acelerar cualquier desarrollo que requiera del uso de dicha API. Eso siempre, siempre que creemos nuestro Mock conforme a la misma especificación que seguirá el API real cuando la tengamos operativa ☺

Postman

Postman mocks

From zero to hero con Mulesoft y su Mocking Service