Estandarización REST en el mundo de los microservicios

REST Standardization microservices

Estandarización REST en el mundo de los microservicios

Introducción

Antes de adentrarnos en la estandarización REST en el mundo de los microservicios, para aquellos que no conocen el concepto REST, podríamos definirlo como un estilo de arquitectura software para una comunicación cliente-servidor, a través de peticiones HTTP.

HTTP define un conjunto pequeño de operaciones, donde las más importantes son: GET, POST, PUT y DELETE. Todas ellas pueden ser invocadas a través de servicios REST y realizar una acción sobre el servidor (típicamente: consultas, inserciones, actualizaciones o borrados).

En la actualidad, está muy de moda debido al auge de los microservicios, siendo la sencillez y legibilidad en el código de programación los grandes puntos a favor. Por otro lado, existen una serie de puntos negativos que podríamos mencionar:

  • Documentación generada: si otro equipo quiere consumir los servicios, necesitará una documentación de todos los servicios REST generados junto con los parámetros necesarios para invocarlos (algo bastante tedioso). Por otro lado, también podemos añadir a los responsables del proyecto, normalmente personal no técnico.
  • Poca estandarización en la implementación: cuando un desarrollador comienza a implementar la solución, muchas veces se encuentra que el lenguaje de programación provee distintos mecanismos, o incluso frameworks de terceros, para realizarlo. Esto provoca que no exista una metodología común de desarrollo, perjudicando el futuro soporte.

 

Una nueva forma de especificar la comunicación REST para todos los públicos

De esta forma, surge la necesidad de definir metalenguajes que sean sencillos de entender por cualquiera, beneficiando a responsables no técnicos y a aquellos equipos que vaya a consumir los servicios desarrollados.

Existen varios metalenguajes/especificaciones en la actualidad, aunque nos quedaremos con “Swagger” y “RAML” para este post. No queremos meternos en profundidad en ninguno de ellos, ya que cada uno tiene sus peculiaridades, aunque si nos interesa que descubráis los conceptos comunes y potencia que nos ofrecen.

Básicamente, en ambos casos todo queda definido mediante un YAML donde se indicará información de los endpoints REST, parámetros de envío, parámetros de respuesta, etc. Como sabéis, también está de moda el uso de YAML ya que son fáciles de leer por un ser humano, al contrario del XML o incluso del JSON.

A continuación, mostraremos un ejemplo de cómo quedaría un fichero YAML:

swagger: '2.0'
host: localhost:8080
basePath: /
scheme:
  http
info:
  version: 0.0.0
  title: Simple-API
  description: my project description
paths:
  /:
    get:
      operationId: myOperationName
      responses:
        - 200:
          description: OK

Como podremos observar a través de la especificación Swagger:

  • Todos nuestros endpoint estarán bajo el host “localhost:8080”
  • Aceptará peticiones “http” (scheme)
  • El endpoint definido es de tipo GET que se invocará siempre que se haga una petición bajo “/”, es decir: http://localhost:8080/
  • Las respuestas que habrá para estas peticiones serán de tipo “200”

Sencillo, ¿verdad? 😉

Estandarizando la implementación de los servicios REST

Como se comentaba en el primer apartado, uno de los problemas que posee el uso de servicios REST es la dificultad para encontrar un método común a todos los desarrolladores.

Existen distintos proyectos en Internet cuya idea principal es procesar una especificación YAML como la mostrada en el punto anterior, para generar código fuente y documentación, y de esta forma, el desarrollador se olvide de cómo implementar la interacción cliente-servidor, preocupándose sólo de su lógica de negocio.

A continuación, aconsejamos que visitéis cualquiera de los siguientes enlaces para que veais las distintas alternativas:

  • Generador de código del BBVA (https://github.com/BBVA-CIB/APIRestGenerator):
    • En la actualidad tiene mucha vida como proyecto en Github.
    • Consume Swagger aunque está pensado en un futuro para parsear también RAML.
    • Genera código servidor Spring MVC y JAXRS, y código cliente JAXRS y Javascript.
    • Una vez generado, es prácticamente “plug & play” ofreciendo además “mocks” aleatorios.
  • Generador de código de Swagger (http://editor.swagger.io/#/)
    • Ofrece distintos tipos de lenguajes de programación como salida a la especificación.
    • El código generado, al contrario que el anterior, sólo ofrece las cabeceras, obligando al desarrollador a implementarlo.
    • Este dominio ofrece también herramientas para una documentación muy visual.