¿Por qué REST?

REST (Representational State Transfer) es un diseño arquitectónico propuesto por Roy Fielding, en su disertación para obtener su doctorado en el año 2000, titulado “Architectural Styles and the Design of Network-based Software Architectures” desarrollado en conjunto con la especificación del HTTP 1.1.

REST se utiliza principalmente como una manera (o medio) de comunicación entre sistemas en el World Wide Web (www).

¿Qué significa “API RESTful”?

“RESTful” implica una serie de características que tendrá Evolution como producto, gracias a la creación de un API Rest:

• Arquitectura Cliente/Servidor. Una aplicación estará formada por un “Cliente” que actualmente se denomina “Frontend” y un “Servidor” que se conoce como “Backend” y que ambas capas forman el sistema completo. Lo importante en este concepto es que no exista ningún tipo de acoplamiento entre el cliente y el servidor, esto permite que cualquier cliente escrito en cualquier lenguaje de programación y sistema operativo, pueda consumir el API.

• El API, se constituye en el Backend de Evolution, mientras que Evolution Wave es la punta de lanza en la que se basará la experiencia de usuario y el interfaz visual, se constituye por lo tanto en el Frontend.

• Debe ser “Stateless”; el Backend NO DEBE salvar ningún tipo de estado entre diferentes peticiones (requests); la gestión de estado se delega exclusivamente en el Frontend. Esto obliga a que cada petición (request) contenga toda la información necesaria para que el Backend entienda lo que debe hacer y contenga la información requerida para hacerlo, de manera independiente a otras peticiones procesadas.

• Debe ser “Cacheable”; el Backend debe implementar un mecanismo de “caching” para mantener el control sobre el tráfico y para mejorar el desempeño del API.

• Interfaz uniforme, cada recurso del API debe tener una única dirección URL para accederlo.

• Arquitectura en capas, que tiene que ver con la separación de responsabilidades en la construcción del API, una capa se encarga de recibir las peticiones, otra de procesar validaciones y reglas de negocio, otra de procesar la operación y finalmente existe una que se conecta a la base de datos y persiste los cambios.

REST y el soporte de HATEOAS

HATEOAS (Hypermedia As The Engine Of Application State]) es una característica importante de cualquier API que implementa REST.

HATEOAS propone la restricción de que cliente y servidor (también llamados consumidor y proveedor) se comuniquen utilizando únicamente Hypermedia. Entendiendo esta última como una extensión del hipertexto (Hypertext), es decir, además de textos simples la comunicación puede incluir archivos, audio, video, imágenes, hipervínculos, etc.

Entonces, un API Restful se enriquece si se soporta la comunicación utilizando Hypermedia, en lugar de Hypertext, ya que soportar HATEOAS brinda las siguientes ventajas:

• Se habilita la posibilidad de retornar archivos adjuntos, incluyendo audio, video, imágenes, etc. Necesario para cumplir con la funcionalidad de Evolution.

• Se permite retornar hipervínculos para acceder a otras áreas del API con información complementaria a la propia entidad (tales como hipervínculo a la información de auditoría o a de flujo de autorización, o hipervínculos a información más detallada sobre los catálogos).

• Le provee al usuario del API, nuevas formas de profundizar en los datos.

Esto permitirá que el cliente tenga menos hipervínculos “quemados” en el código fuente, ya que la propia API genera estos enlaces, para acceder a la información relacionada con la entidad.

Por ejemplo, si pensamos en un recurso que esté asociado a un catálogo, el API puede retornar la URL que permite obtener toda la información del catálogo.

{
  "id": "12345",
  "fabricante": "BMW",
  "modelo": "X5",
  "asientos": 5,
  "conductores": [
    {
      "id": 21,
      "nombre": "Alicia Vikander",
      // Se anexa la URL para acceder a la info completa
      "href": "/api/v1/conductores/21"
    }
  ]
}