REST es un acrónimo que significa (REpresentational State Transfer) Transferencia de Estado Representacional y es una manera de crear APIs. Es una arquitectura de desarrollo de aplicaciones introducida en el año 2000 por Roy Fielding como parte de su disertación doctoral.

Esta arquitectura que propone algunos principios que ayudan a que una aplicación web sea estándar y de fácil uso por casi cualquier dispositivo conectado a internet. Pero para comenzar a entender estos sistemas, hay algo que es muy importante para esta clase de sistemas:

Sistemas basados en recursos

Los sistemas creados con rest deben ser sistemas basados en recursos, no en acciones. Por ejemplo, piensa en un sistema encargado de gestionar ordenes en una pizzería, en este sistema una "Orden" sería un recurso, mientras que "cambiar orden" es una acción. Del mismo modo, el "Repartidor" sería un recurso, mientras que "Repartir pizza" es una acción.

Principios de REST

Cliente-Servidor

Esto se refiere a que para que REST exista deben haber dos actores, un cliente que consuma y un servidor que almacen o genere información.

Stateless

El hecho de que no almacena estado se refiere a que el servidor no almacena información del cliente para servir a los propósitos de la aplicación. Toda la información necesaria para hacer funcionar a la aplicación debe provenir del cliente.

Esto significa que las peticiones deben ser autocontenidas, deben proveer la autenticación en caso de ser necesarias, deben contener el tipo de operación que se va a realizar o la información que se debe modificar… etcétera.

Interfaz Uniforme

Los recursos se exponen a través de URIs, direcciones http como las que pones en la barra del navegador. Siguiendo con restricción de que debe estar centrado en recuros, es importante que en estas direcciones no se haga referencia a acciones. Por ejemplo, /order es una uri válida, mientras que /order/edit no lo es.

Las acciones para manipular los recursos se especifican dentro de la petición misma, no en la dirección del recurso.

Representaciones

A pesar de que es una arquitectura basada en recursos, la información que se transmite entre cliente y servidor no es más que la "representación" del recurso. También es importante que pueden existir más de una representación de un recurso, que estos dependerán del nivel de detalle que requiere la operación que se está realizando.

Por ejemplo estas podrían ser dos representaciones de un mismo recurso pero que sirven distintos propósitos:

{
	"id": 2,
	"paid": false
	"time_placed": "18:25:43-05:00",
	"customer": "Antonio Feregrino",
    "served": false
}  
  

    </pre>
</div>
<div class="pure-u-1-2">
    <pre>



{
"id": 2,
"paid": false
"time_placed": "18:25:43-05:00",
"customer": {
"name": "Antonio",
"type": "frequent"
}
}

Para manipular los recursos se usan algunos los verbos HTTP:

  • POST para crear recursos
  • GET para obtener un recurso
  • PUT para actualizar un recurso
  • DELETE para eliminar un recurso

Tal tal vez estas operaciones te podrán resultar familiares si has trabajado con sistemas CRUD, y es que esa es la idea, que exista un set de operaciones estándares a las que cualquier dispositivo capaz de realizar peticiones http pueda realizar. No estás obligado a implementar todas las operaciones para cada recurso, pero si a usar estas operaciones para manipular los datos.

Prioriza el uso de hypermedia

La forma en que los desarrolladores trabajan con esta información es a través de "hypermedia", ¿tal vez has escuchado el termino "HATEOAS" o Hipermedia Como Motor del Estado de la Aplicación? pues bien, lo que esto significa que de algún modo, el estado de las aplicaciones se maneja a través de hipermedia, o para que no quede tan libre este término, enlaces.

Las representaciones de los recursos con los que responde el servidor deben incluir enlaces a otros recursos relacionados, en el caso de las órdenes de pizza tal vez podríamos tener algo como esto:

"links": [{
    "rel": "self",
    "href": "http://localhost:8080/order/425"
},{
    "rel": "payment",
    "href": "http://localhost:8080/order/425/payment"
},{
    "rel": "deliveryperson",
    "href": "http://localhost:8080/order/425/deliveryperson"
}]

Cacheable

Parte del almacenamiento que puede suceder en el cliente es el cacheo de las peticiones, esto con la finalidad de reducir la carga en el servidor y agilizar el tiempo de respuesta. La responsabilidad de establecer si un recurso puede o no ser cacheado depende del recurso que se esté manejando. Por ejemplo, peinsa en un recurso llamado "Reporte de ventas", cuya URI sea /reporteventas que actualiza una sola vez al día, justo a la 1 de la mañana, ¿qué sentido tendría tener que solicitarle al servidor más de una vez al día el reporte de ventas si siempre nos va a resonder con la misma información?

Eso sí, el cacheo depende completamente del cliente y este puede decidir ignorar la información que tiene en la caché y hacer las peticio9nes de cualquier modo.

Sistema Multicapa

Una aplicación cliente no sabe inicialmente (ni debería interesarle) si está conectada directamente con el servidor o si hay componentes intermedios que incrementan la seguridad o distribuyen la carga entre los servidores de la aplicación.

Haciendo un servicio RESTful

De nueva cuenta, y como con todos los otros conceptos de los que les he hablado aquí, podrías decidir no implementar REST al 100%, sin embargo a diferencia de los otros conceptos, REST es algo que está expuesto a un tercero y lo ideal sería que si prometes que tienes un servicio RESTful, (así se le llama a los servicios que exponen una API que cumple al 100% con REST), lo cumplas por completo.

Con la creciente demanda de servicios web en el mundo REST ha tomado una popularidad impresionante, y al menos por ahora es el rey de las APIs en el internet... bueno, contando solo las que están expuestas al público.

Por ahí existen otras formas de obtener información en la web: el corporativo protocolo SOAP y el nuevo lenguaje GraphQL... pero estos se merecen un post completo.

Frameworks

Bien, para terminar hay que decir que si vas a hacer una aplicación web que funcione bajo los principios REST, no tienes que hacerlo solo. Hay diversos frameworks como Sinatra y Grape para Ruby, LoopBack y ExpressJS para JavaScript, Slim y Silex para PHP, Nancy y Web API para C#, que te pueden ayudar a tu cometido.