conceptosRest
REST es un estilo arquitectural para sistemas distribuidos hipermedia. Permite describir la arquitectura de la Web como un gran sistema distribuido hipermedia. Su característica principal es que define una interfaz uniforme entre los componentes del sistema. En la Figura 1, si imaginamos que cada círculo es un componente de la Web (pensemos en cualquier cosa que se puede acceder por internet) y que cada línea representa que dos componentes se pueden comunicar, lo que estamos diciendo con interfaz uniforme es que la forma como están hechas las líneas es la misma: el protocolo de comunicación es el mismo no importa cuáles sean los servicios que cada componente ofrece ni quién lo haya desarrollado.
El protocolo más utilizado para implementar esta arquitectura es HTTP (Hypertext Transfer Protocol).
 |
|---|
| Figura 1: Los nodos en la Web |
Sin embargo, la arquitectura REST no es solo el protocolo, también incluye la forma como entendemos los componentes de la Web.
Cada componente se define en términos de los recursos que maneja y no de los servicios que ofrece.
Por ejemplo, si pensamos en algo como Spotify, como componente de la Web, identificamos que los recursos que manipula son canciones, discos, artistas. Si nuestro ejemplo fuera banner, los recursos serían estudiante, profesor, curso, etc.
Los componentes que conforman el sistema (la Web) manejan recursos. Cada recurso tiene una manera única de identificarlo (su URI), tiene una o más representaciones y le pertenece a alguien. Los recursos pueden ser una página Web, un video, un sonido, una animación, un objeto JSON, un xml, etc.
URI: "Uniform Resource Identifiers" (URIs) sirve para identificar de manera única un recurso de la red. Una URI contiene una URL (Uniform Resource Locator) para localizar el recurso y un nombre URN (Uniform Resource Name).
La sintaxis genérica de un URI sigue la siguiente forma:
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]
Ejemplos de esto son:
Ejemploshttp://www.yourserver.com/logo.gif
En este caso:
-
http es el
schema -
www.yourserver.com es el
host -
logo.gif es el
path(el nombre del recurso)
http://www.google.com/search?q=low
En este caso:
-
http es el
schema -
www.google.com es el
host -
search es el
path -
q=low es el
query
Una descripción más detallada sobre el formato de las URIs puede ser encontrada aquí: Formato de las URIs
Un recurso puede tener distintas formas de representarlo. Los recursos son más que páginas, imágenes o videos, también representan información que maneja la aplicación, por ejemplo: los empleados de una compañía, los estudiantes de una universidad. Para representar estos recursos existen varios formatos como por ejemplo: XML o JSON, siendo JSON el más popular.
Si quisiéramos representar un recurso empleado, en alguna aplicación por ejemplo de una nómina de una compañía, utilizando JSON podemos definir:
Un recurso empleado:
{"empleados":[
{"nombre":"Juan", "apellido":"Perez"},
{"nombre":"Ana", "apellido":"Gutierrez"},
{"nombre":"Pedro", "apellido":"Ruiz"}
]}Este mismo ejemplo en formato XML:
<empleados>
<empleado>
<nombre>Juan</nombre> <apellido>Perez</apellido>
</empleado>
<empleado>
<nombre>Ana</nombre> <apellido>Gutierrez</apellido>
</empleado>
<empleado>
<nombre>Pedro</nombre> <apellido>Ruiz</apellido>
</empleado>
</empleados>En esta arquitectura, sin importar cuál sea el recurso, las operaciones que se pueden hacer sobre ellos son siempre las mismas. Básicamente estas son: Obtenerlo (GET), crearlo (POST), borrarlo (DELETE), actualizarlo (PUT).
El protocolo HTTP es una forma de implementar la arquitectura REST; este protocolo define los verbos que indican la acción que se efectúa sobre el recurso. Los más importantes son GET, POST, PUT, DELETE que leen, crean, modifican o borran un recurso. Por ejemplo, si en un navegador escribimos la siguiente URL:
www.mislibros.com/elmasvendido.pdf
El navegador localiza el recurso en la dirección www.mislibros.com y su petición es un GET. El componente que se está ejecutando en la dirección www.mislibros.com entiende la petición GET y devuelve el recurso llamado elmasvendido.pdf (en representación pdf) o, si no lo encuentra, un error HTTP 404 not found.Cuando el navegador recibe la respuesta, ya sea el recurso o el error, se lo muestra al cliente quien lo solicitó.
La sigla REST significa: REST: Representational State Transfer. Expliquemos con un ejemplo: 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 se requiere para que app2 la responda. Decimos que viaja o que se transfiere el estado. Si por ejemplo, app2 necesita las credenciales de autenticación de quien está haciendo la petición, estas deben viajar con la petición. La aplicación app2 no guarda el estado de quien está interactuando con ella, en nuestro ejemplo, no guarda las credenciales de app1. Si la misma app1 hace otra petición, debe enviar de nuevo dichas credenciales. Esta característica permite que las aplicaciones escalen fácilmente porque las aplicaciones no necesitan mantener conexiones por largo tiempo y se pueden reutilizar.
Aunque Roy Fielding acuñó el término REST en su tesis doctoral en el año 2000 es hasta ahora que esta arquitectura se ha popularizado. Una de las razones, a parte de su simplicidad, está en el significado de la sigla "Representational State Transfer". Decimos que una aplicación es Restful sí ofrece un API siguiendo las convenciones de la arquitectura REST: utiliza HTTP de acuerdo con la semántica definida de los verbos, tiene una definición clara de sus recursos , tanto de su identificación como de sus representaciones, y no mantiene un estado con los clientes.
