REST es uno de los conceptos más importantes en los círculos de desarrollo centrados en la web de hoy. Probablemente hayas escuchado sobre él incluso si tu enfoque principal no es el desarrollo web. A pesar de su popularidad, hay mucha confusión sobre lo que realmente es. Echemos un vistazo a algunos conceptos para entender mejor qué significa ser RESTful.
Todo comienza con un tipo llamado Roy
El término REST se origina de la disertación doctoral de Roy Fielding, Estilos Arquitectónicos y el Diseño de Arquitecturas de Software basadas en Red. Es, en esencia, un estilo arquitectónico para sistemas de hipermedia distribuidos cuyo objetivo principal es la interoperabilidad entre servicios web.
Un grupo de restricciones define la arquitectura y dicta pautas sobre cómo los servicios web deberían interactuar entre sí. Un sistema es RESTful siempre y cuando cumpla con todas estas restricciones. El aspecto más importante de REST es que no te dice cómo implementar tus componentes o qué protocolo usar. Todos los principios se refieren a la interacción entre componentes y la interpretación de los datos intercambiados.
En REST, el Recurso es la principal abstracción de información
Los recursos representan cosas como personas, edificios, el valor de las acciones en un momento dado, y también colecciones de estas cosas. En otras palabras, los recursos son cualquier cosa a la que puedas ponerle un nombre.
Debido a que necesitas una forma de identificar un recurso particular (a menudo para obtener accesso), tienen identificadores de recursos. La mayoría de las implementaciones modernas usan URLs para esta tarea. Por ejemplo, una forma de obtener un recurso específico de manzana podría ser http://myapiexample/apples/{apple-resource-id}.
La representación de un recurso es otro concepto importante. Las representaciones consisten en los datos usados para describir un recurso más sus metadatos asociados. Estas representaciones pueden tomar la forma de imágenes o documentos HTML, o también JSON o XML. No confundas un recurso con su representación: puedes representar el mismo recurso como HTML o JSON. Esta desvinculación entre un recurso y su representación te permite acceder a ellos en una gran variedad de formatos.
Las 6 restricciones arquitectónicas
Hay seis restricciones arquitectónicas que definen cómo debería verse un sistema REST. Su objetivo es proporcionar una forma consistente de estructurar un sistema y al mismo tiempo proteger la creatividad del desarrollador. Debido a esto, las restricciones son principios guía que dejan los detalles de implementación al ingeniero.
1. Cliente-servidor
En primer lugar, el sistema debe adherirse a una arquitectura cliente-servidor. El principal beneficio es la separación de responsabilidades, permitiendo que la interfaz de usuario y el almacenamiento de datos evolucionen independientemente el uno del otro. Además, la interfaz de usuario se vuelve más portable ya que los clientes solo necesitan conocer la URI de un recurso para usarlo.
En sistemas modernos, el servidor es usualmente una aplicación backend ejecutándose en un servidor físico o en la nube. El cliente, por otro lado, es una aplicación ejecutándose en un navegador web o un dispositivo móvil. La mayoría de las aplicaciones web y móviles en uso hoy en día se adhieren a este principio, comunicándose con un servidor usando internet.
2. Sin estado
La comunicación entre servidor y cliente debe ser sin estado (stateless). En otras palabras, toda la información requerida para entender una solicitud debe ser incluida con ella. Como resultado, la comunicación con el backend no necesita hacer uso de ningún contexto almacenado en el servidor. Según Fielding, este enfoque proporciona los siguientes beneficios:
- Visibilidad, porque los sistemas de monitoreo solo necesitan mirar una solicitud para entenderla.
- Confiabilidad, porque es más fácil recuperarse de fallas parciales cuando no hay estado volátil en el servidor.
- Escalabilidad, porque el servidor no necesita administrar/almacenar datos a través de solicitudes, haciendo más fácil liberar recursos.
Cuando se requiere estado, el cliente lo mantiene (usualmente como una cookie) y lo envía en cada solicitud subsiguiente.
Aunque este enfoque proporciona beneficios importantes, es importante también considerar sus desventajas:
- Enviar datos repetitivos en cada solicitud aumenta el uso de la red.
- El servidor pierde algo de control sobre el comportamiento consistente de la aplicación, ya que la implementación correcta del cliente se vuelve más importante.
3. Cacheable
Esto significa, en esencia, que debes etiquetar los datos dentro de una respuesta como cacheables o no cacheables. El principal beneficio es un mejor rendimiento general enviando menos solicitudes al servidor gracias a los valores en caché. El caché debe administrar los datos apropiadamente, de lo contrario, se volverán obsoletos y desactualizados.
4. Interfaz Uniforme
Probablemente la restricción más importante del estilo arquitectónico REST.
Requiere que el sistema presente una interfaz uniforme entre componentes. Debido a la regularidad ofrecida al mantener una interfaz uniforme, la arquitectura de todo el sistema se vuelve mucho más simple. Por otro lado, todos los datos deben ajustarse a una forma estandarizada, algo que puede degradar la eficiencia. Hay 4 principios que aseguran la uniformidad:
- Identificación de recursos: los recursos necesitan tener un identificador único, permitiéndote recuperar y operar en cualquiera de ellos.
- Manipulación de recursos a través de representación: los recursos pueden ser enviados al cliente en diferentes formatos, como JSON, XML, PNG, que son representaciones de dicho recurso. Debido a que las aplicaciones REST pueden ofrecer varias representaciones para el mismo recurso, los clientes pueden indicar cuál desean recibir. Después, puedes agregar y actualizar recursos enviando representaciones del elegido desde el cliente al servidor. Por ejemplo, un servicio puede permitirte crear una ‘Persona’ aceptando cualquiera de las siguientes representaciones:
{
"Person":{
"name": "Person Example",
"occupation": "Test subject",
"age": 23,
"interests": ["be useful", "serve as example"]
}
}
<Person>
<Name>Person Example</Name>
<Occupation>Test subject</Occupation>
<Age>23</Age>
<Interests>
<Interest>be useful</Interest>
<Interest>serve as example</Interest>
</Interests>
</Person>
- Mensajes autodescriptivos: las solicitudes del cliente y las respuestas del servidor se llaman mensajes. Tener mensajes autodescriptivos significa que incluyen toda la información necesaria para darles sentido. La mayoría de las implementaciones de REST logran esto proporcionando métodos estándar (como las acciones de HTTP) y usando tipos de medios para indicar semántica.
- Hipermedia como el motor del estado de la aplicación: el término hipermedia se refiere a cualquier contenido que tiene enlaces a otro contenido o medios. En REST, las respuestas del servidor usualmente incluyen enlaces de hipermedia, permitiendo a los clientes atravesar recursos a través de ellos. Además, las solicitudes para un recurso usualmente incluyen enlaces para alterar su estado. Por ejemplo, las implementaciones usando HTTP rutinariamente incluyen enlaces para enviar solicitudes POST y PUT para alterar o crear un recurso. En esencia, REST te proporciona una forma de alterar el estado de la aplicación haciendo uso de hipermedia.
5. Sistema en capas
Este es el enfoque clásico de diseñar el sistema en capas. El sistema es una jerarquía donde los componentes de cada capa tienen objetivos y comportamiento específicos. Igualmente importante, cualquier componente no puede ver más allá de la capa inmediata con la que interactúa.
6. Código bajo demanda (opcional)
Esto significa que los servicios RESTful pueden devolver código ejecutable si hay necesidad de hacerlo. El objetivo principal es reducir el número de funcionalidades que los clientes necesitan implementar permitiéndoles descargarla después. En el desarrollo web moderno, puedes considerar descargar y ejecutar javascript como una forma de código-bajo-demanda. Fielding considera esto una restricción opcional, tu servicio puede ser REST incluso si no proporciona características de código-bajo-demanda.
Bien, ¿pero qué hay de GET, POST y todo eso?
REST y HTTP no son la misma cosa; el primero es un estilo arquitectónico mientras que el segundo es un protocolo. Hay una idea equivocada común de que todas las APIs RESTful deberían usar verbos HTTP como GET, PUT y POST. En verdad, puedes usar cualquier protocolo sin estado y llamar a tu API RESTful siempre y cuando cumpla con las restricciones.
Fielding nunca mencionó ningún protocolo específico para implementar servicios RESTful. Sin embargo, el uso de HTTP en la capa de transporte es ampliamente soportado por bibliotecas de software e infraestructura de servidores. Como resultado, la mayoría, si no todos, los servicios RESTful hoy en día usan HTTP en lugar de otros protocolos.
Es útil conocer lo básico
Debido a su enorme popularidad, REST es un término que escucharás una y otra vez si trabajas en desarrollo web. Saber que REST es más que solo recibir y responder a verbos HTTP es ya más de lo que la mayoría de la gente sabe sobre el tema. Entonces, para recapitular lo que acabamos de aprender:
- REST es un estilo arquitectónico para construir sistemas de hipermedia
- El recurso es la principal abstracción de información en sistemas RESTful
- Los recursos y sus representaciones son entidades desacopladas
- El objetivo de REST es lograr un sistema escalable, tolerante a fallas y extensible aplicando un conjunto especial de restricciones
- Un sistema es RESTful si cumple con las restricciones guía establecidas por Fielding
- REST y HTTP son cosas diferentes, el segundo es un protocolo
- Un sistema puede usar protocolos sin estado distintos a HTTP y aún ser RESTful
Espero que leer esto sea tan útil para ti como escribirlo fue para mí.
Qué hacer a continuación:
- Comparte este artículo con amigos y colegas. Gracias por ayudarme a llegar a personas que podrían encontrar útil esta información.
- Lee el trabajo original de Roy Fielding.
- Envíame un email con preguntas, comentarios o sugerencias (está en la página Autor)