REST es el acrónimo de REpresentational State Transfer. Es un estilo arquitectónico para sistemas hipermedia distribuidos y fue presentado por primera vez por Roy Fielding en 2000 en su famosa disertación.

al igual que cualquier otro estilo arquitectónico, REST también tiene sus propias 6 restricciones de guía que deben satisfacerse si una interfaz necesita ser referida como RESTful. Estos principios se enumeran a continuación.,

Principios Rectores de REST

1. cliente–servidor: al separar las preocupaciones de la interfaz de usuario de las preocupaciones de almacenamiento de datos, mejoramos la portabilidad de la interfaz de usuario en múltiples plataformas y mejoramos la escalabilidad simplificando los componentes del servidor.
2. Sin estado: cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud y no puede aprovechar ningún contexto almacenado en el servidor. Por lo tanto, el estado de la sesión se mantiene completamente en el cliente.,
3. Cacheable-las restricciones de caché requieren que los datos dentro de una respuesta a una solicitud se etiqueten implícita o explícitamente como cacheable o no cacheable. Si una respuesta se puede almacenar en caché, se le da a una caché de cliente el derecho de reutilizar esos datos de respuesta para solicitudes equivalentes posteriores.
4. interfaz uniforme: al aplicar el principio de ingeniería de software de generalidad a la interfaz de componentes, se simplifica la arquitectura general del sistema y se mejora la visibilidad de las interacciones., Para obtener una interfaz uniforme, se necesitan múltiples Restricciones arquitectónicas para guiar el comportamiento de los componentes. REST se define por cuatro restricciones de interfaz: identificación de recursos; manipulación de recursos a través de representaciones; mensajes auto-descriptivos; e hipermedia como el motor del Estado de la aplicación.
5. Sistema en capas: el estilo de sistema en capas permite que una arquitectura esté compuesta de capas jerárquicas al restringir el comportamiento de los componentes de manera que cada componente no pueda «ver» más allá de la capa inmediata con la que están interactuando.,
6. Code on demand (opcional) – REST permite ampliar la funcionalidad del cliente descargando y ejecutando código en forma de applets o scripts. Esto simplifica a los clientes al reducir el número de características requeridas para ser pre-implementadas.

Resource

la abstracción clave de la información en REST es un recurso. Cualquier información que se pueda nombrar puede ser un recurso: un documento o imagen, un servicio temporal, una colección de otros recursos, un objeto no virtual (por ejemplo, una persona), y así sucesivamente., REST utiliza un identificador de recurso para identificar el recurso particular involucrado en una interacción entre componentes.

el estado del recurso en cualquier marca de tiempo en particular se conoce como representación de recursos. Una representación consiste en datos, metadatos que describen los datos y enlaces hipermedia que pueden ayudar a los clientes en la transición al siguiente estado deseado.

el formato de datos de una representación se conoce como tipo de medio. El tipo de medio identifica una especificación que define cómo se procesará una representación. Una API verdaderamente RESTful parece hipertexto., Cada unidad de información direccionable lleva una dirección, ya sea explícitamente (por ejemplo, atributos de enlace e id) o implícitamente (por ejemplo, derivado de la definición de tipo de medio y la estructura de representación).

según Roy Fielding:

hipertexto (o hipermedia) significa la presentación simultánea de información y controles de tal manera que la información se convierte en la asequibilidad a través de la cual el usuario (o autómata) obtiene elecciones y selecciona acciones. Recuerde que el hipertexto no necesita ser HTML (o XML o JSON) en un navegador., Las máquinas pueden seguir enlaces cuando entienden el formato de datos y los tipos de relación.

Además, las representaciones de recursos deben ser auto-descriptivas: el cliente no necesita saber si un recurso es empleado o dispositivo. Debe actuar sobre la base del tipo de medio asociado con el recurso. Por lo tanto, en la práctica, terminará creando muchos tipos de medios personalizados, Normalmente un tipo de medio asociado con un recurso.

cada tipo de medio define un modelo de procesamiento predeterminado., Por ejemplo, HTML define un proceso de renderizado para el hipertexto y el comportamiento del navegador alrededor de cada elemento. No tiene ninguna relación con los métodos de recurso GET / PUT/POST/ DELETE / other aparte del hecho de que algunos elementos de tipo media definirán un modelo de proceso que va como «los elementos de anclaje con un atributo href crean un enlace de hipertexto que, cuando se selecciona, invoca una solicitud de recuperación (GET) en el URI correspondiente al atributo href codificado en CDATA.,»

Métodos de recursos

otra cosa importante asociada con REST son los métodos de recursos que se utilizarán para realizar la transición deseada. Un gran número de personas relacionan erróneamente los métodos de recursos con los métodos HTTP GET/PUT/POST/DELETE.

Roy Fielding nunca ha mencionado ninguna recomendación sobre qué método usar en qué condición. Todo lo que hace hincapié es que debe ser interfaz uniforme. Si decide que HTTP POST se utilizará para actualizar un recurso, en lugar de que la mayoría de la gente recomiende HTTP PUT, está bien y la interfaz de la aplicación será RESTful.,

idealmente, todo lo que se necesita para cambiar el estado del recurso será parte de la respuesta de la API para ese recurso, incluidos los métodos y en qué estado dejarán la representación.

se debe ingresar una API REST sin ningún conocimiento previo más allá del URI inicial (marcador) y el conjunto de tipos de medios estandarizados que son apropiados para la audiencia deseada (es decir, que se espera que entienda cualquier cliente que pueda usar la API)., A partir de ese momento, todas las transiciones de estado de la aplicación deben ser impulsadas por la selección del cliente de las opciones proporcionadas por el servidor que están presentes en las representaciones recibidas o implícitas por la manipulación de esas representaciones por parte del usuario. Las transiciones pueden ser determinadas (o limitadas por) el conocimiento del cliente de los tipos de medios y mecanismos de comunicación de recursos, los cuales pueden ser mejorados sobre la marcha (por ejemplo, código bajo demanda).,

otra cosa que le ayudará al construir API RESTful es que los resultados de API basados en consultas deben estar representados por una lista de enlaces con información de resumen, no por matrices de representaciones de recursos originales porque la consulta no es un sustituto de la identificación de recursos.

REST y HTTP no son lo mismo !!

mucha gente prefiere comparar HTTP con REST. REST y HTTP no son lo mismo.

REST !,= HTTP

sin embargo, debido a que REST también tiene la intención de hacer que la web (internet) sea más eficiente y estándar, aboga por usar los principios de REST de manera más estricta. Y ahí es donde la gente intenta empezar a comparar REST con web (HTTP). Roy fielding, en su disertación, en ninguna parte mencionó ninguna directiva de implementación, incluyendo cualquier preferencia de protocolo y HTTP. Hasta el momento, usted está honrando los 6 Principios Rectores de descanso, puede llamar a su interfaz RESTful.,

en palabras simples, en el estilo arquitectónico REST, los datos y la funcionalidad se consideran recursos y se accede a ellos utilizando identificadores de recursos uniformes (Uri). Se actúa sobre los recursos mediante el uso de un conjunto de operaciones simples y bien definidas. Los clientes y servidores intercambian representaciones de recursos mediante el uso de una interfaz y un protocolo estandarizados, normalmente HTTP.

Los recursos están desacoplados de su representación para que se pueda acceder a su contenido en una variedad de formatos, como HTML, XML, texto sin formato, PDF, JPEG, JSON y otros., Los metadatos sobre el recurso están disponibles y se utilizan, por ejemplo, para controlar el almacenamiento en caché, detectar errores de transmisión, negociar el formato de representación adecuado y realizar autenticación o control de acceso. Y lo más importante, cada interacción con un recurso es apátrida.

todos estos principios ayudan a que las aplicaciones RESTful sean simples, livianas y rápidas.