REST es la abreviatura de Transferencia de Estado Representacional

 

Pero más allá de esas siglas Rest es un mundo que tenemos por descubrir cuando vamos a desarrollar  APIs. Toda persona involucrada en el mundo del desarrollo ha escuchado sobre REST o RESTful por todas partes, sin embargo, puede que no tengamos una idea clara de lo qué es.

Debido a esto se han creado ciertas concepciones equivocadas sobre REST que hoy vamos a desmentir. Algunas de las más comunes son:

  • REST es un patrón de arquitectura para aplicaciones web como MVC
  • REST es un protocolo como  SOAP
  • Si una Web API es construida en HTTP, entonces es una RESTful web API.

 

Aproximadamente hay tres generaciones de tecnología para crear API web y exponer los poderes de computación del lado del servidor a los clientes en toda la web.

 

La primera generación se conoce como llamada de procedimiento remoto  (RPC), arquitectura de corredor de solicitud de objeto común(CORBA), entre otras.

 

La segunda generación se conoce como Lenguaje de descripción de servicios web (WSDL) y tecnologías basadas en el Protocolo simple de acceso a objetos (SOAP) como Windows Communication Foundation (WCF).

 

La tercera generación es servicios web RESTful. Una vez que aplicamos las restricciones del estilo arquitectónico REST correctamente, al diseñar e implementar un servicio web, este servicio web se convierte en un servicio web RESTful.

 

Actualmente, seguimos llamando a esos servicios web no RESTful y llamamos a la API RESTful, Web Services, RESTful Web API o simplemente API web.


magic-wandNota:

Hay muchas tecnologías que podemos usar para construir APIs web RESTful, como ASP.NET Core, ASP.NET MVC, NodeJS, Spring MVC, etc.


 

Podemos comparar a REST con un contrato, que cuenta con restricciones y cláusulas que se aplican bajo ciertas circunstancias y puntos críticos. Podemos aplicar REST en dos niveles:

 

  1.       Nivel de arquitectura
  2.       Nivel de diseño de API

 

A Nivel de Arquitectura

Rest es un estilo  Arquitectónico para sistemas distribuidos. Podemos considerar un sistema distribuido a una aplicación cliente/servidor. Puede constar tanto de una o varias aplicaciones que se comuniquen a través de la red. Veamos con más detalles las reglas que deben seguir las API bajo este esquema o estilo:

 

  • Stateless, en la arquitectura  REST, el cliente hace un request para acceder al recurso que necesita del servidor, a su vez el servidor responde ese request para retornar el resultado o respuesta correspondiente al cliente. Cada petición desde cualquier cliente contiene toda la información necesaria del servidor para entender la petición y tomar las acciones necesarias. El servidor no almacena ninguna sesión del cliente, o data relaciona, en cambio el cliente puede almacenar en caché dicha información para futuras peticiones.

 

  • Caché, una forma de mejorar la eficiencia de la conexión, el cliente tiene la capacidad de almacenar las respuestas. Por ejemplo, un usuario busca una lista de libros filtrado por autor, Jane Austen. Cuando el cliente web, obtenga la respuesta, debería almacenar la respuesta, pues el resultado no va a cambiar en poco tiempo. La siguiente vez, que el usuario haga esta búsqueda antes de que el caché expire, el cliente puede usar esta data inmediatamente, sin costarle recursos al servidor.

 

  • Arquitectura Cliente-servidor: Esta restricción permite mantener la interface separa del almacenamiento de la data. Debido a la aplicación de esta restricción es posible que las API sean portables, además brinda a los desarrolladores  flexibilidad para usar la misma API en diferentes plataformas.  

 

  • Identificación  de Recursos, Este elemento es fundamental y distintivo en el estilo arquitectónico de REST. Actualmente existen muchas formas de unificar interfaces con los componentes de aplicación web, pero Rest elige una manera muy simple, para aprovechar los métodos HTTP.

 

  • Manipulación de los recursos a través de representaciones, Toda la data /información necesitada por el servidor para tomar acciones, están completamente cubiertas en la representación transferida por las peticiones.

 

  • Sistema de capas,  si una API es desarrollada para soportar un sistema de capas, el desarrollo del servidor se pueden mejorar muchos pliegues teniendo un mecanismo de equilibrio de carga en su lugar.

 

  • Interfaz Uniforme, Esta es una de las mas importantes restricciones en el diseño de API REST y ayuda a desacoplar la arquitectura, lo que resulta en la evolución independiente de los componentes. Las cuatro variantes de esta restricción son:
  1. Identificación de recursos en las solicitudes.
  2. Manipulación de recursos a través de la representación
  3. Mensajes autodescriptivos
  4. Hipermedia como el motor del estado de la aplicación

 

A nivel de diseño de API

Los servicios web Restful permiten establecer la interoperabilidad entre los sistemas computaciones y el internet. Las API Restful  usan las peticiones HTTP para realizar las acciones GET, PUT, POST, PATCH and Delete. Mientras diseñamos un API, debemos tener en cuenta las siguientes propiedades.

www.dominiotic.com

Reglas o restricciones a nivel de diseño:

 

  • Content Negotiation: Se refiere a un mecanismo definido como parte de HTTP, la cual hace posible servir diferentes versión de documento bajo la misma URL.

 

  • Plantillas URL : La creación de plantillas URL habilita la composición de URL para el cliente. Además, ayuda a los usuarios finales a documentar los patrones de acceso a la URL.
  • Design for Intent: Las APIs no pueden exponer la lógica interna de negocios. Por lo tanto, las API deben desarrollarse para garantizar que cumplan con los requisitos de los casos de los usuarios, proporcionados y enfrentado por los usuarios.

 

  • Versionado:  Si una API es diseñada y cumple con todas las expectativas y requerimientos es un escenario ideal. Sin embargo, en caso de que no funcione como se esperaba , el desarrollador debe hacer modificaciones a la versión existente de la API. Por tanto, es siempre una buena práctica agregar un número, para mantener el control de las versiones de las API.

 

  • Autorización: Una API  RESTful debe ser capaz de asignar y modificar la autorización de derechos, para permitir leer y sobreescribir el acceso a los recursos basados en los requerimientos. Por tanto el API debe ser capaz de delimitar cuales recurso u objetos serán mostrados a determinado usuario.

 

  • Operaciones en Bloque(Bulk operations): La API debe ser capaz también de suportar operaciones bulk. 

 

  • Registro de Errores: El desarrollador de una API debe asegurarse que el proceso de coleccion los mensajes de error está optimizada y bien definida.

 


Conclusiones

Antes de leer sobre el tema puede que tuviéramos ideas equivocadas sobre lo que es y no es REST, el propósito de este articulo es explicar de forma simple en que consiste este estilo arquitectónico y cuando es aplicable. Espero que les sea útil, no olviden dejarme saber su opinión.