REST es una definición de estilo de arquitectura aplicada a las aplicaciones en red. Existe como una serie de restricciones aplicadas a la implementación de componentes de red, que permiten una semántica de interfaz uniforme, en lugar de implementaciones y sintaxis específicas de la aplicación.
REST como arquitectura de red fue documentada por primera vez por Roy Fielding en su tesis doctoral titulada Architectural Styles and the Design of Network-based Software Architectures, publicada en 2000. REST permite a los clientes interactuar con los datos almacenados en un servidor, sin tener ningún conocimiento previo del servidor o de lo que existe en él.
REST son las siglas de Representational State Transfer (transferencia de estado representacional). Los puristas de las siglas suelen escribirlo como ReST, porque la E de REST en realidad no significa nada. Es sólo la segunda letra de la palabra "representacional". Así se evitan controversias sobre cómo pronunciarlo, como la que ha asolado al TI en los últimos años. Con la E incluida, no hay confusión al pronunciar el acrónimo más preciso de RST como "muñeca" o incluso como R-S-T.
Las alertas personalizadas y la visualización de datos le permiten identificar y prevenir rápidamente los problemas de salud y rendimiento de la red.
No existe una definición o norma específica de lo que es REST. Como arquitectura, REST define cómo se enlazan los distintos componentes a través de conectores y cómo se intercambian datos a través de interfaces. REST es una serie de restricciones o requisitos que, cuando se cumplen, crean una implementación del estilo arquitectónico REST.
La arquitectura REST no fomenta la creación de métodos adicionales específicos para cada situación. Por ejemplo, una arquitectura REST utilizaría el método GET para recuperar datos en cualquier circunstancia. El único cambio para los diferentes tipos de datos serían los diferentes parámetros. Esto contrasta con la creación de un nuevo método para obtener información sobre un usuario (getUser), y otro método para obtener información sobre precios (getPricing), etc.
La interfaz de usuario en el cliente está separada y es independiente del almacenamiento de datos en el servidor. Esto permite implementar y modificar el cliente independientemente de lo que ocurra o no en el servidor. Del mismo modo, los datos del servidor pueden utilizarse y modificarse independientemente de cómo acceda a ellos el cliente. Este diseño permite que los sistemas cliente y servidor evolucionen a su propio ritmo, independientemente unos de otros.
No deben almacenarse datos de sesión en el servidor entre peticiones del cliente. En otras palabras, cada transacción debe llevar consigo la capacidad de comprender la solicitud por completo sin necesidad de acceder a ningún contexto o dato adicional almacenado en el servidor. Todos los datos de sesión deben residir exclusivamente en el cliente.
Esta restricción permite simplificar el equilibrio de carga o la tolerancia a fallos. Un servidor diferente podría responder a todas y cada una de las peticiones de un cliente y devolver los mismos datos que tendría el servidor original, siempre y cuando ambos servidores tengan los mismos datos originales. No hay necesidad de pasar ningún tipo de datos específicos de la sesión entre estos servidores de equilibrio de carga. Las sesiones que no son apátridas pueden dar lugar a respuestas diferentes si la petición es procesada por un servidor diferente, porque sólo el servidor anterior tendría datos específicos de esa sesión con el cliente.
En cada intercambio, los datos deben marcarse como almacenables en caché o no almacenables en caché. Los datos almacenables en caché pueden ser almacenados y reutilizados por el cliente. Los datos no se almacenan en caché en el servidor porque esto violaría la restricción de no tener estado. La posibilidad de almacenar datos en caché reduce el ancho de banda necesario para mantener una sesión cliente-servidor sin estado.
Para lograr una interoperabilidad total, la interfaz se desvincula del tipo de datos siempre que todas las interacciones funcionen de la misma manera. Cuatro subcondiciones garantizan la uniformidad de las interfaces: identificación de recursos, manipulación de recursos mediante representaciones, mensajes autodescriptivos e hipermedia como motor del estado de la aplicación (HATEOAS).
Cualquier información que pueda nombrarse es un recurso. Un recurso puede ser cualquier forma de dato. Un identificador de recurso es una forma de referirse a un recurso específico en un momento determinado. Tales recursos pueden actualizarse en el servidor sin que el cliente necesite tener un conocimiento previo, ya que cada solicitud se describe y responde por completo.
Una representación es el estado actual de un recurso, junto con los metadatos que lo acompañan y que permiten comprender la representación. El formato de los datos de una representación define su tipo de medio. Así, un cliente puede solicitar un recurso, como una imagen, a un servidor utilizando el identificador de recurso de ese recurso (probablemente una URI), y una representación de esa imagen compuesta por los bytes que componen la imagen, junto con los metadatos que definen el formato de datos como un tipo de medio JPG será devuelta al cliente, que podrá entonces mostrar la imagen al usuario.
Cada mensaje del cliente al servidor debe contener toda la información necesaria para procesar el mensaje. En el caso de la seguridad y la autenticación, el token de seguridad debe intercambiarse en cada mensaje.
Las cookies son muy populares en Internet. El acto de comprobar la cookie frente a todos los datos de cada mensaje sería un ejemplo de mensaje no autodescriptivo y, por tanto, no sería técnicamente RESTful.
Definición de hipermedia
Hipermedia es similar al concepto de hipertexto o hipervínculos, salvo que abarca todas las formas de medios y no sólo texto o enlaces. Se trata de una forma no lineal de proporcionar información o datos, normalmente siguiendo un enlace u otro marcador en un recurso publicado, como una página web. Los hipermedios pueden ser texto, gráficos, vídeo u otras formas de datos.
En HATEOAS, un cliente interactúa a través de una red mediante hipermedia
El cliente interactúa con un servidor utilizando únicamente hipermedia. Ese mismo hipermedia es entregado dinámicamente por el servidor en respuesta a una petición RESTful. Como resultado, no se requiere ningún conocimiento previo de los datos de un servidor, ni de su estructura, ni de cómo se almacenan esos datos. En su lugar, sólo es necesario utilizar una estructura y unos métodos hipermedia bien definidos.
En un sistema de capas jerárquicas, ningún componente puede interactuar ni ver ningún dato o interfaz salvo en su propia capa inmediata. Por consiguiente, el cliente no necesita saber cómo conectarse a ningún servidor, proxy, cortafuegos, enrutador o punto final adicional, ni siquiera si es necesario hacerlo. Más bien, cualquier intermediario continuará conectándose a los servidores subsiguientes de acuerdo con las restricciones REST, y la respuesta resultante a cualquier solicitud devuelta a través de los intermediarios al cliente también será compatible con REST. Por lo tanto, los cambios o interrupciones en los sistemas intermediarios son invisibles para el cliente, lo que permite que dichos sistemas intermediarios proporcionen equilibrio de carga, seguridad u otras funciones.
Aunque técnicamente se considera opcional, los clientes de una arquitectura REST deben poder descargar y ejecutar secuencias de comandos. Esto permite la ampliación de funcionalidades y sistemas más complicados, sin dejar de proporcionar la misma comunicación de estilo REST entre cliente y servidor. Al igual que con las peticiones y respuestas básicas, toda la instrucción para ejecutar el código de script debe ser independiente y no requerir una implementación previa en el cliente.
Por ejemplo, un cliente web puede ejecutar JavaScript que recibe del servidor. Aunque el código reside en el servidor, no se ejecuta allí. El código se envía al cliente como parte de la solicitud y el cliente lo ejecuta de acuerdo con su implementación. Esta es la razón por la que la correcta implementación de estándares en los clientes web es tan crítica; de lo contrario, el mismo código del servidor puede ser ejecutado con diferentes resultados en diferentes clientes.
Las notificaciones en tiempo real significan una solución de problemas más rápida para que pueda actuar antes de que se produzcan problemas más graves.
Los componentes de un sistema REST se comunican a través de una representación de un recurso en uno de los diversos formatos normalizados acordados, como formatos gráficos, formatos de documentos y diversos formatos web. De nuevo, para ser un verdadero sistema REST, cada transacción debe contener la capacidad de recuperar e interpretar el recurso deseado.
Un recurso es cualquier cosa que pueda ser nombrada. Es el recurso almacenado en el servidor para ser solicitado por el cliente. Un recurso puede ser un archivo estático, un documento, una base de datos, una imagen o cualquier otro formato que pueda ser solicitado.
Aunque ahora es un concepto común, la idea original de un recurso como elemento genérico, cambiante y puntual fue una característica clave de REST y de la web en general. Un recurso es cualquier dato nombrable en un servidor. Esos datos pueden cambiar no sólo a una versión más reciente de los mismos datos, sino incluso a un tipo completamente diferente de datos. Esto permite que los datos de un servidor se actualicen en cualquier momento sin necesidad de que ningún cliente lo sepa de antemano, una característica clave de la interoperabilidad y la disponibilidad.
El identificador de recurso es la ubicación específica del recurso solicitado. En el caso de un sistema basado en HTTP, el identificador de recurso es la URL o URI. El identificador de recurso especifica un único recurso. Un único identificador de recurso puede referirse a diferentes datos, o recursos, en diferentes momentos. En un sistema compatible con REST, el cliente no necesita saber de antemano qué tipo de recurso está solicitando el identificador de recurso. La respuesta incluirá metadatos que describen cómo interpretar los datos recibidos.
Por ejemplo, aunque una solicitud de URL indique /servidor/index.html, si el recurso en esa dirección devuelve una representación como archivo de imagen, junto con los metadatos correspondientes, el archivo de imagen seguirá mostrándose correctamente independientemente de lo que dijera el identificador del recurso.
Se refiere a los datos enviados al cliente. Como se mencionó anteriormente, la representación debe ser uno de los formatos de datos estandarizados. Los datos no se procesan en el servidor, sino que son interpretados por el cliente. Por ejemplo, un cliente que solicita un documento HTML no recibe un gráfico que se mostrará en el monitor, sino un conjunto de código HTML que se interpreta y se muestra en el cliente. Otros ejemplos de representación son los archivos gráficos como las imágenes JPEG y GIF.
Los metadatos de representación proporcionan información sobre la representación al sistema. Como ocurre con la mayoría de los metadatos, los metadatos de representación no suelen formar parte de lo que se muestra al usuario final. Los metadatos de representación pueden incluir el tipo de medio, la fecha de creación y modificación y el número de versión.
Los metadatos de recursos son información adicional proporcionada al sistema sobre el recurso que existe en el servidor en lugar de la representación mostrada en el cliente. Entre los ejemplos de metadatos de recursos se incluyen enlaces de origen, alternativas e información sobre el recurso. Por ejemplo, los metadatos de recursos pueden incluir texto alternativo que se mostrará en caso de que una representación de imagen no pueda mostrarse por alguna razón (por ejemplo, texto de imagen ALT en HTML).
Los datos de control se refieren principalmente a la validez del recurso y su representación en el cliente. Los datos de control incluyen si los datos son almacenables en caché o no, así como el tiempo de caducidad absoluto, o proporcionan un límite sobre el tiempo de uso de los datos. Los datos de control también pueden incluir una suma de comprobación u otros medios para garantizar la integridad.
En conjunto, la arquitectura REST crea un marco altamente escalable, completamente transparente y reutilizable, en el que los clientes están desvinculados de las implantaciones de servicios en los servidores. Es independiente de la plataforma, tanto para el cliente como para el servidor. Es independiente del lenguaje y de la estructura. No importa si los datos se encuentran en una base de datos, son recuperados por un proceso de servidor Java y enviados a un programa local -como un navegador- codificado en una de varias versiones de C.
En la web moderna, REST se implementa utilizando un vocabulario estándar común entre cliente y servidor conocido como Protocolo de Transferencia de Hipertexto, o HTTP. Sin embargo, cualquier implementación que se ajuste a todos los principios de la arquitectura REST se considera RESTful. HTTP no es la única posibilidad.
Aunque HTTP y REST no son lo mismo, HTTP en su forma original es una implementación de REST. Esto no es sorprendente si se tiene en cuenta que Roy Fielding estaba trabajando en el protocolo HTTP 1.1, mientras desarrollaba la arquitectura REST.
Cada recurso se identifica mediante un identificador uniforme de recursos (URI). Normalmente, esto se implementa como una URL dentro de un navegador web. Un URI identifica un recurso. No se requiere ningún conocimiento previo del sistema en el que reside el recurso en el servidor. Además, el URI (o URL) puede especificar la representación de un recurso sin necesidad de conocer su estructura de archivos.
En HTTP, la representación de recursos se implementa mediante el soporte de varios tipos de archivos dentro de un navegador HTTP. Así, los metadatos que acompañan a un recurso definen uno de los varios formatos de archivo ampliamente soportados, como HTML, CSS, JPG, GIF, etc.
Una implementación REST pura de HTTP requiere el uso de cuatro métodos básicos: GET, POST, PUT y DELETE. Cada método debe utilizarse explícitamente y asignarse a una de cada una de las acciones principales RETRIEVE DATA, CREATE RESOURCE, UPDATE RESOURCE y DELETE RESOURCE.
Algunos métodos HTTP deben ser idempotentes. Idempotente significa que la ejecución del mismo método con los mismos parámetros debe devolver siempre el mismo resultado. Para que esto funcione, el método en cuestión no puede provocar ninguna modificación en el servidor que haga que se devuelva un resultado diferente para la misma petición. En la práctica, una petición idempotente no debe modificar los datos del servidor.
Se utilizan para recuperar un recurso o información sobre el mismo. Aunque la mayoría de las implementaciones de HTTP procesarán parámetros con una solicitud GET para modificar o crear recursos, tal acción no sería compatible con una implementación RESTful. Las peticiones GET deben ser idempotentes.
Una petición POST crea nuevos datos en un servidor. Por definición, una solicitud POST NO es idempotente. Con cada ejecución, una petición POST crearía más datos.
Al igual que una petición POST, una petición PUT modifica datos existentes. Por ejemplo, cambiar el apellido de un usuario existente. Las peticiones PUT no son intuitivamente idempotentes. Aunque una solicitud PUT modifica datos, lo hace siempre de la misma manera. Así, una solicitud PUT que cambie el apellido de un usuario siempre producirá el mismo resultado, siempre que todos los parámetros sean coherentes.
Una petición DELETE elimina o borra datos, como su nombre indica. Las peticiones Delete también son idempotentes en el sentido de que ejecutar una repetidamente siempre dará como resultado el mismo estado final con los datos en cuestión ya no existiendo en el servidor. Sin embargo, para el cliente, puede parecer que hay una diferencia en el hecho de que una vez que un recurso es borrado, la petición puede ser respondida con un mensaje de error como archivo no encontrado. Sin embargo, el método sigue considerándose idempotente, ya que no importa qué error se envíe durante la transacción, el estado final de dicha solicitud es el mismo que la primera vez que se solicitó.
PRTG es un software de monitoreo de red integral y realiza un seguimiento de toda su infraestructura de TI.
En una entrada de su blog, ahora abandonado, Roy Fielding analizaba los criterios que debe cumplir una API para ser considerada verdaderamente RESTful. Partiendo de su tesis publicada anteriormente, este post describía los mismos conceptos de arquitectura REST que deberían aplicarse a las API.
Así, una API de RESTful es aquella que utiliza ÚNICAMENTE la arquitectura REST sin necesidad de documentación o métodos adicionales más allá de los que se ajustan al modelo. Fielding proporcionó los siguientes puntos como aclaración de lo que hace que una API sea RESTful.
Una API verdaderamente RESTful no debería depender de ningún protocolo y debería ser capaz de soportar cualquier protocolo que utilice URI para la identificación. De lo contrario, la identificación no está separada de la interacción.
Una API de REST no debería requerir cambios en los protocolos estandarizados, en particular la adición de funciones adicionales. Siempre que sea posible, cualquier solución necesaria debe definirse por separado con el objetivo de eliminarla por completo una vez que ya no sea necesaria.
El espacio de nombres de un servidor debe ser independiente de la definición y los requisitos de la API. En otras palabras, la API debería funcionar con cualquier servidor compatible con REST, no sólo con servidores que se ajusten a una determinada especificación de API.
