• Giovanny Rey Cediel

Arquitectura REST

Actualizado: ago 1

REpresentational State Transfer (REST), es un estilo arquitectónico de software para ser usado en servicios Web.


Toda arquitectura de software descansa en el principio de abstracción: ocultar detalles de funcionamiento, mediante encapsulación y exposición de interfaces para interacción con los clientes. La abstracción fundamental en el estilo de arquitectura REST es el recurso. Un recurso es un objeto que tiene tipo, atributos, relaciones con otros recursos, y un conjunto de métodos que operan sobre él. Es como un objeto en lenguaje Java, pero con la diferencia fundamental de que sus métodos corresponden con los métodos HTTP estándar: GET, POST, PUT, PATH y DELETE.


El estado de los recursos en el tiempo se conoce como representación. Una representación de recursos consta de datos y enlaces de hipertexto que ayudan a los clientes a manipular el estado de los recursos. Por ejemplo, una URI como la siguiente: /usuarios, emitida con el método PUT actualizará un usuario representado con datos enviados en el cuerpo del mensaje HTTP. En este ejemplo podemos identificar la representación del recurso con los datos, el enlace de hipertexto con el método HTTP y el URI. Una API verdaderamente RESTful parecerá hipertexto, tal como se describe en el post: Diseño de API REST.



CARACTERÍSTICAS


REST tiene seis principios guía de los cuales uno es opcional. Cualquier interfaz que prentenda considerarse RESTful debe seguir los principios que se enumeran a continuación.


1. Arquitectura cliente servidor

En esta arquitectura un programa (el servidor) proporciona servicios tales como almacenar información en una base de datos o realizar tareas de cálculo a petición de otro programa (el cliente). Esta característica permite que el desarrollo del cliente y el servidor ocurra independiente uno del otro.


2. Sistema en capas

La característica clave de un sistema basado en capas, es que los componentes de cada capa solamente interactúan entre ellos y con componentes de capas adyacentes, en otras palabras, una capa no puede "ver" más allá de la capa inmediata con la que está interactuando. Por ejemplo, podemos citar un sistema web que se organiza en tres capas: presentación, aplicación y datos. La capa de presentación, compuesta por el Web Browser y Web Server interactúan entre sí para buscar y retornar información que los usuarios del sistema requieren. La capa de aplicación, realiza procesamientos para retornar contenidos adecuados conforme a reglas de negocio, esta capa usa los servicios de la capa de datos cuya función es almacenar la información de forma segura y consistente.

3. Interacciones sin estado

Cada solicitud del cliente al servidor debe contener toda la información necesaria para que el servidor la comprenda y pueda procesar la respuesta, porque el servidor no dependerá de la información enviada de solicitudes anteriores. Esta restricción mejora el rendimiento de los servicios Web porque el servidor no tiene que almacenar ninguna información sobre los estados actuales de los clientes en el sistema. Sin embargo, esta característica impone restricciones significativas en la forma en que un cliente y un servidor se comunican. Cada vez que un cliente envía una solicitud debe proporcionar y almacenar información sobre su estado. Por ejemplo, si un servidor necesita autenticación para que un cliente tenga acceso a datos, el cliente debe enviar la información de autenticación en cada solicitud.


4. Cacháble para los clientes

Los clientes pueden conservar una copia local de una respuesta del servidor para usarla en solicitudes posteriores. Básicamente, cada vez que un servidor responde a una solicitud del cliente, el servidor agrega información a la respuesta para etiquetarla como almacenable o no almacenable. En caso de ser alamcenable, en la respuesta se indicará el tiempo que debe durar la respuesta en caché. Con HTTP esto se especifica en el Header Cache-Control con la directiva max-age=<seconds>. Esto permite mejorar el rendimiento y reducir la cantidad de solicitudes al servidor. También puede disminuir algunos de los impactos negativos de aplicar la restricción stateless (sin estado) del lado del servidor.


5. Interfaz uniforme de comunicación entre el cliente y el servidor

Para garantizar una interfaz de comunicación uniforme entre el cliente y el servidor, por una parte, se requiere que el recurso se identifique en la solicitud utilizando un identificador uniforme de recursos, URI, por las siglas de Uniform Resource Identifier.


Por otro lado se requieren métodos que entienda tanto el cliente como el servidor. REST usa los métodos HTTP comunes: GET, POST, PUT, PATH y DELETE para comunicar las diferentes acciones que el cliente desea realizar en el recurso.


Finalmente, se espera que las representaciones de los recursos sean uniformes. Para ello se usan encabezados específicos en las respuestas —que indican como tratar la información— y los recursos se representan específicamente de tres maneras: XML, JSON o Texto simple.

6. Código en demanda (opcional)

Como ultima característica opcional, REST permite que la funcionalidad cliente sea extendida mediante la obtención de código del servidor en forma de applets o scripts. Por ejemplo, si se sabe que el software de los clientes dentro de una organización admite Java, entonces los servicios dentro de esa organización pueden construirse de modo que los clientes obtengan el beneficio de una funcionalidad mejorada descargando clases java provistas por el servidor, lo cual simplifica la implementación del lado del cliente.


Estas seis características definen una arquitectura REST. En este punto el lector puede preguntarse ¿como incluirlas en el diseño de sus servicios?. La respuesta la veremos en el post: Diseño de API REST.


Copyright Giovynet.com 2018 - 2020