Aquí va mi resumen personal para leer en cinco minutos, al que volveré dentro de un tiempo cuando se me haya olvidado, y espero que me sirva de refresco. Quien quiera más detalles, abajo encontrará algunos enlaces. Básicamente, lo que resumo aquí se basa en un 70-80% en el primer enlace, que es el que más útil me ha parecido de los que he encontrado hasta ahora.
Fig. 1. REST es un conjunto de ideas de las que destacan 4 tomates principios.
Imagen de Softeis - Trabajo propio, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=143779
Imagen de Softeis - Trabajo propio, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=143779
1. Qué es REST
Un conjunto de principios de arquitectura para el desarrollo de aplicaciones y servicios web.
Surge en oposición a SOAP y WSDL, que son más complicados.
Grandes proveedores 2.0 usan APIs RESTful (Google, Facebook...)
El énfasis se pone en los recursos (¿objetos?) y su transferencia por HTTP.
2. Principios básicos
2.1. Uso explícito de métodos HTTP
Se deben utilizar como se definieron en la especificación original de HTTP 1.1 (RFC 2616). Esto significa:
- GET para consultas
- POST para altas
- PUT para actualizaciones
- DELETE para ...¿lo adivinas?
Usar un GET para insertar o actualizar un registro en una BD es posible pero no es acorde con los principios RESTful.
2.2. Protocolo cliente/servidor sin estado
Cada petición HTTP debe contener toda la información necesaria.
Esto debe facilitar la escalabilidad, no se debe hacer que un servidor recupere el contexto si, por ejemplo, tiene que redirigir la petición a otro servidor para balanceo de carga.
Se transfiere el problema de mantener el estado al cliente.
Aunque a la hora de la práctica, aplicaciones que se definen como RESTful suelen usar cookies y otras formas de mantener el estado. ??
2.3. Exponer URIs como directorios y ficheros
Las URIs son así más intuitivas. Por ejemplo: http://www.dominio.com/informes/2016/04 nos podría devolver los informes de abril de 2016. Es una especie de sintaxis universal.
También se oculta la tecnología (no se ven extensiones de archivos, como ocurre en casos como http://www.dominio.com/informes/recuperar_informes.php donde se ve que se utiliza PHP). Así se puede cambiar la tecnología subyacente sin cambiar la URI.
Parece que este es el principio más REST de los cuatro.
4. Los recursos se devuelven en XML, HTML o JSON
Por ejemplo, un registro de una BD. Estos recursos pueden contener enlaces (URIs) a otros recursos.
3. Ideas importantes
Al exponer los recursos mediante una API RESTful, se facilita la integración de aplicaciones de diferente naturaleza y tecnologías. Se puede proporcionar una base de servicios REST que pueden utilizar otras aplicaciones más complejas para construir sobre ellos.
No todas las implementaciones públicas que se definen como REST son RESTful. Parece que el principio predominante que sí se suele respetar es el de la URI uniforme (principio 3), como podemos ver, por ejemplo, aquí.
También he detectado un poco de bombo en torno al término REST, pero esto es inevitable en esta profesión, donde los nuevos términos se utilizan a menudo como el equivalente tecnológico de cojonudo.
4. Más info
- RESTful Web services: The basics
- Versión en español del artículo anterior
- Artículo en la Wikipedia en español (mejor leerlo después de leer el primer enlace)
- Servicios que son "accidentalmente" RESTful
He leído también detalles en otras páginas, pero son cosas más puntuales, y nada que no podáis superar con una simple búsqueda.
