Conceptos básicos de REST
¿Qué es REST?
Sección titulada «¿Qué es REST?»REST (Representational State Transfer) es un estilo arquitectural para sistemas distribuidos hipermedia: describe cómo deberían comunicarse entre sí los componentes de un sistema como la Web. Su característica principal es que define una interfaz uniforme entre esos componentes: cualquier componente se comunica de la misma forma con cualquier otro, sin importar qué servicios ofrezca ni quién lo haya construido. El protocolo y la forma de definir los servicios son siempre los mismos.
El protocolo más utilizado para implementar REST es HTTP (Hypertext Transfer Protocol).
REST no es solo el protocolo: también es una forma particular de pensar los componentes de un sistema.
Por ejemplo, si pensamos en Spotify como componente de la Web, los recursos que maneja son canciones, discos y artistas. Si pensamos en un sistema como Banner, los recursos serían estudiante, profesor, curso, etc. Diseñar el API empieza por nombrar esos recursos, no por listar operaciones.
Identificación de los recursos
Sección titulada «Identificación de los recursos»Cada recurso tiene una forma única de identificarlo (su URI), una o más representaciones, y le pertenece a alguien. Un recurso puede ser una página web, un video, un objeto JSON, un XML, etc.
URI — Uniform Resource Identifier — identifica de manera única un recurso en la red. Una URI contiene una URL (Uniform Resource Locator) para localizar el recurso, y puede incluir además un nombre (Uniform Resource Name). La sintaxis genérica de una URI es:
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]httpHostwww.google.comPath/searchQueryq=lowEn este ejemplo, http es el esquema, www.google.com es el host, /search es el path (el nombre del recurso) y q=low es la query, el parámetro de búsqueda.
Otro ejemplo, más simple, sin query:
httpHostwww.miservidor.comPath/logo.gifAquí http es el esquema, www.miservidor.com el host y /logo.gif el path: el nombre del recurso que se quiere obtener.
Representación de los recursos
Sección titulada «Representación de los recursos»Los recursos no son solo páginas, imágenes o videos: también representan información que maneja una aplicación, como los empleados de una compañía o los estudiantes de una universidad. Para representar esa información existen formatos estándar, siendo JSON el más popular (también se usa XML).
Por ejemplo, el recurso empleados de una aplicación puede representarse en JSON como:
{ "empleados": [ { "nombre": "Juan", "apellido": "Pérez" }, { "nombre": "Ana", "apellido": "Gutiérrez" }, { "nombre": "Pedro", "apellido": "Ruiz" } ]}El mismo recurso, en formato XML:
<empleados> <empleado> <nombre>Juan</nombre> <apellido>Pérez</apellido> </empleado> <empleado> <nombre>Ana</nombre> <apellido>Gutierrez</apellido> </empleado> <empleado> <nombre>Pedro</nombre> <apellido>Ruiz</apellido> </empleado></empleados>En ambos casos la decisión de diseño fue la misma: un empleado se representa por su nombre y su apellido. Lo que cambia es únicamente el formato de representación: JSON en el primer caso, XML en el segundo. Nota que en los dos casos aparece tanto el nombre del atributo como su valor.
Operaciones sobre los recursos
Sección titulada «Operaciones sobre los recursos»En esta arquitectura, sin importar cuál sea el recurso, las operaciones que se pueden hacer sobre él son siempre las mismas: obtenerlo, crearlo, actualizarlo o borrarlo. El protocolo HTTP implementa esto con verbos que indican la acción que se efectúa sobre el recurso:
| Verbo HTTP | Acción sobre el recurso |
|---|---|
| GET | Lo obtiene (read) |
| POST | Lo crea (create) |
| PUT | Lo actualiza (update) |
| DELETE | Lo borra (delete) |
Por ejemplo, si en un navegador escribimos www.mislibros.com/elmasvendido.pdf, el navegador localiza el recurso en www.mislibros.com y hace una petición GET. El componente que atiende esa dirección entiende el GET y devuelve el recurso elmasvendido.pdf (en formato PDF) o, si no lo encuentra, un error HTTP 404 Not Found. El navegador recibe la respuesta —el recurso o el error— y se la muestra a quien la solicitó.
El significado de “state transfer”
Sección titulada «El significado de “state transfer”»La sigla REST significa Representational State Transfer: cuando una aplicación app1 hace una petición REST a otra aplicación app2, con esa petición viaja toda la información que app2 necesita para responderla. Decimos que el estado viaja, o se transfiere, con cada petición.
Si por ejemplo app2 necesita las credenciales de autenticación de quien hace la petición, esas credenciales deben viajar con la petición: app2 no guarda el estado de quien interactúa con ella. Si app1 hace otra petición más adelante, debe volver a enviarlas. Esta característica —no mantener estado entre peticiones— es la que permite que las aplicaciones REST escalen con facilidad: no necesitan mantener conexiones abiertas por mucho tiempo, y sus recursos se pueden reutilizar entre clientes distintos.
Decimos que una aplicación es RESTful si ofrece un API que sigue las convenciones de esta arquitectura: usa HTTP respetando la semántica de sus verbos, define con claridad sus recursos —tanto su identificación como sus representaciones— y no mantiene estado con los clientes entre una petición y otra.