Estas son las notas del primer capitulo del libro Hands-On RESTful API Design Patterns and Best Practices que recomiendo encarecidamente adquirir, ya que aclara los conceptos que aquí apenas se mencionan. Lo siguiente es un resumen que está lejos de tener el valor de todos los matices que abarca el libro.
Algunos conceptos o definiciones previos:
XML/JSON (Extensible Markup Language/ JavaScript Object Notation) es el formato que provee metadata para los datos que son contenidos dentro de los mensajes que intercambian los sistemas/servicios
SOAP (Simple Object Accces Protocol): usado para para transferir datos.
WSDL (Web Services Description Language) : se usa para definir los servicios disponibles que pueden ser consumidos
UDDI (Universal Description, Discovery, and Integration) es una lista de los servicios disponibles.
URI (Uniform Resource Identifier) se usa para identificar la ubicación de recursos en una red.
API (Application Programming Interface) especifica como un componente de software se comunica con otros componentes.
REST (Representational State Transfer) es una manera o estilo de exponer funciones y datos para ser consumidos en un ambiente distribuido.
SOA (Service Oriented Architecture): define estándares y enfoques para el diseño de web services y cómo estos se comunican entre sí. Aquí, un web service es la representación lógica actividades de negocio repetibles, son una operación que tienen un resultado específico: obtener el costo de un producto, actualizar el inventario, obtener la ubicación de un negocio. Para el consumidor el webservice que consume es una caja negra. Estas alojados en servidores e interactúan con otras aplicaciones a través de interfaces.
ROA (Resourse Oriented Architecture): es una arquitectura fundada en la semántica de la web. Define un diseño estructural y guías para soportar e implementar interacciones con cualquier recurso conectado. En este contexto, cualquier entidad de negocio puede ser representado por como un recurso y pude ser accesible a través de una URI. Así en un sistema de recursos humanos cada empleado es una entidad (servicio) y sus detalles, salario, perfil, son asociaciones (descriptores) de una entidad y cada entidad puede permitir varias acciones (contratos).
Como se apuntó ROA está fundamentada en la semántica de la web ¿Cuál semántica? Las operaciones o “verbos” que implementa el protocolo HTTP , es decir:
| VERBO | USO |
|---|---|
| GET | Leer las representaciones de un recurso |
| PUT | Creación de un nuevo recurso. |
| DELETE | Eliminación del recurso (y de los recursos ligados, de forma opcional) |
| POST | Modificación del recurso. |
| HEAD | Meta información del recurso. |
Ahora, para decir con propiedad que tenemos una API que es REST ésta debe cumplir con ciertas restricciones y propiedades (dadas por Roy Fielding, quien propuso en primera instancia el concepto de REST) Entre las propiedades están: se exponen recursos, no se mantiene estado entre requests, direccionabilidad (el recurso debe usar una dirección), uniformidad y usar el protocolo HTTP para la comunicación de los datos.
Entre las restricciones (Constraints) REST están:
- Cliente-Servidor: La comunicación se da entre el cliente (o muchos clientes) que es quien quién solicita un servicio, utilizándolos mediante el envio de requests, y el servidor que es quien provee el servicio a consumir, manejando los request o solicitudes para acceder a los mismos. Clientes y servidor típicamente existen en un ambiente distribuido comunicándose a través de una red por medio de patrón request-respond.
- Statelessness (sin estado): Significa que el servidor no mantiene ninguna información o estado contextual entre los requests. Dicho de otra forma cada llamado (request) del cliente debe contener toda la información necesaria de manera explícita para que el servidor pueda entenderlo y manejarlo de manera totalmente independiente. Esto asegura escalabilidad y confiabilidad del lado del servidor. Es importante señalar que es el cliente, entonces, quien debe mantener algún mecanismo para mantener contexto entre las llamadas al servidor.
- Caching (Caché): en el contexto de REST se refiere a la posibilidad almacenar datos de uso frecuente de manera que parcial o totalmente se elimine la necesidad de la comunicación entre el cliente y el servidor, disminuyendo la latencia y mejorando el rendimiento en el lado del cliente. Hay diversas estrategias para el caching: browser caché, proxy caché, gateway cache (reverse proxy). Usualmente se usan algunos tags a nivel de headers para controlar el cache: expires, Cache-control,E-Tag, Last-Modified. (más información).
- Interfaz Uniforme: como se mencionó anteriormente se refiere a la combinación de la semántica del HTTP, con el concepto de recurso, creando una interfaz uniforme. Es decir donde GET, es siempre leer, y DELETE es siempre eliminar con respecto a un recurso cualquiera este sea. Esto es parte del corazón de REST, Roy Fielding, instituyó cuatro principios necesarios para alcanzar a cabalidad la restricción de interfaz uniforme:
- Identificación de los recursos: cada recurso debe estar identificado inequívocamente por medio de un URI. Así el URI para ubicar un empleado será https://api.MyRRHH.com/1.1/Planilla/Empleados/:id.json los datos devueltos podrán refinarse y mejorase con la evolución de las versiones pero está siempre será la forma de acceder al recurso empleado.
- Manipulación del recurso: se refiere a la independencia del URI de un recurso y los formatos en la que la información es devuelta al cliente. Puede que la misma URI exponga el recurso solicitado en diferentes formatos: JSON, XML, HTML, PNG, SVG, etc (Multipurpose Internet Mail Extension (MIME)) permitiendo que el cliente manipule esta data según sus posibilidades y conveniencia. Para lograr esto el servidor habilita a través del tag Accept del Http header que el cliente le solicite el formato en que requiere el recurso. Separar la representación (formato) del recurso de la URI del mismo es un aspecto crucial de REST.
- Mensajes Auto-Descriptivos: REST descansa sobre el principio de que tanto el request del cliente como el response del servidor son estandarizados (tienen cuerpo y metadata) y son autodescriptitvos es decir usan los tipos de mensajes: GET, HEAD, OPTIONS, PUT, POST y DELETE) de manera que son completamente comprendidos tanto por el servidor como por el cliente. De esta manera se tiene el mecanismo por medio del cual los mensajes contienen la información necesaria, manteniéndose cada uno independiente, sin necesidad de mantener estados en el servidor.
- Hypermedia como el motor de Estado de Aplicación (Hypermedia as the Engine of Application State (HATEOAS)): Sin esta característica no podemos argumentar que un servicio es RESTful, fue introducida en el modelo Richardson Maturity Model (RMM) por Leonard Richardson. Se trata del siguiente paso una vez tenemos un servicio que expone un recurso a través de un URI accesible a por medio de los verbos de HTTP, y consiste en brindar al cliente que consume un recurso la guía de qué es lo siguiente que puede hacer con él. Esto se realiza por medio de un dato más denominado de forma estándar “link” o “links” que acompaña la respuesta del servidor. Para ponerlo menos abstracto imaginemos un servicio que nos devuelve una lista de las citas disponibles de un doctor, con HATEOAS a cada uno de los ítems devueltos se le añade un dato link que nos indica cual es el URI para tomar esa particular cita de manera que el cliente es guiado al siguiente paso o estado de la aplicación. Resumiendo, HATEOAS se refiere a que la representación de un recurso devuelta por un servicio incluye links que le indican a quien lo consume recursos relacionados con el mismo.
- Sistemas en capas: consiste en sistemas que se componen de unidades que se comunican a través de interfaces predefinidas desempeñando diversas funciones. Estas capas puede estar físicamente separadas de manera que, por ejemplo, la API REST se instala en el servidor A, la autenticación se realiza en el servidor B y los datos se almacenan el servidor C. REST sugiere que los servicios pueden estar constituidos por múltiples capas, que éstas publican contratos de servicios y que, en un ordenamiento jerárquico, la lógica de una capa dada únicamente puede ser conocida por la capa inmediatamente superior o inmediatamente inferior.
El mismo Roy Fielding, fundador del estilo REST, dejó claro que para que un API (servicio) se atribuya el estatus de RESTful debe cumplir con las restricciones de su estilo de arquitectura, es decir cumplir con:
- Cliente-Servidor
- Statelessness
- Caching
- Interfaz Uniforme
- Sistema en capas.
- Rendimiento
- Escalabilidad
- Simplicidad
- Modificabilidad
- Visibilidad
- Portabilidad
- Confiabilidad
- Testeability (susceptible de probarse)
