Qué es REST

  • Por
  • API
Puede que te suene por las API REST. Te explicamos por qué se han popularizado tanto en el mundo de Internet y qué características tienen estos sistemas.

Actualmente, las API REST están realmente de moda: parece que cualquier aplicación deba proporcionar su “API REST”. Pero...¿qué significa realmente una API REST?

REST deriva de "REpresentational State Transfer", que traducido vendría a ser “transferencia de representación de estado”, lo que tampoco aclara mucho, pero contiene la clave de lo que significa. Porque la clave de REST es que un servicio REST no tiene estado (es stateless), lo que quiere decir que, entre dos llamadas cualesquiera, el servicio pierde todos sus datos. Esto es, que no se puede llamar a un servicio REST y pasarle unos datos (p. ej. un usuario y una contraseña) y esperar que “nos recuerde” en la siguiente petición. De ahí el nombre: el estado lo mantiene el cliente y por lo tanto es el cliente quien debe pasar el estado en cada llamada. Si quiero que un servicio REST me recuerde, debo pasarle quien soy en cada llamada. Eso puede ser un usuario y una contraseña, un token o cualquier otro tipo de credenciales, pero debo pasarlas en cada llamada. Y lo mismo aplica para el resto de información.

El no tener estado es una desventaja clara: tener que pasar el estado en cada llamada es, como mínimo, tedioso, pero la contrapartida es clara: escalabilidad. Para mantener un estado se requiere algún sitio (generalmente memoria) donde guardar todos los estados de todos los clientes. A más clientes, más memoria, hasta que al final podemos llegar a no poder admitir más clientes, no por falta de CPU, sino de memoria. Es algo parecido a lo que ocurre con la web tradicional (que también es stateless). Sea cual sea la tecnología con la que desarrolles para web, seguro que conoces que puedes crear lo que se llama una “sesión”. Los datos de la sesión se mantienen entre peticiones y son por cada usuario. El clásico ejemplo de sesión puede ser un carrito de la compra, entre las distintas peticiones web, la información del carrito de compra se mantiene (¡ojo! hay otras alternativas para implementar carritos de compra).

Por norma general, la sesión se almacena en la memoria RAM del servidor, por lo que es fácil quedarnos sin memoria si introducimos demasiados datos en sesión (o tenemos muchos usuarios simultáneos). Por supuesto, podemos utilizar varios servidores, pero como bien saben los desarrolladores web, mover la sesión contenida en memoria entre servidores es generalmente imposible o altamente ineficiente, lo que penaliza el balanceo de carga, lo que a su vez redunda en menor escalabilidad y menor tolerancia a fallos. Hay soluciones intermedias, tales como guardar la sesión en base de datos, pero su impacto en el rendimiento suele ser muy grande. De hecho, el consejo principal para desarrollar aplicaciones web altamenteescalables es: no usar la sesión.

Así pues, tenemos que el ser stateless es la característica principal de REST, aunque por supuesto no la única. Así, cualquier servicio REST (si quiere ser merecedor de ese nombre) debería no tener estado, pero no cualquier servicio sin estado es REST. Hay otros factores, pero vamos a destacar el que los ingleses llaman “uniform interface” y es lo que diferencia un servicio web clásico (orientado a RPC) de un servicio REST.

SOAP y REST

SOAP es el acrónimo de “Simple Object Access Protocol” y es el protocolo que se oculta tras la tecnología que comúnmente denominamos “Web Services” o servicios web. SOAP es un protocolo extraordinariamente complejo pensado para dar soluciones a casi cualquier necesidad en lo que a comunicaciones se refiere, incluyendo aspectos avanzados de seguridad, transaccionalidad, mensajería asegurada y demás. Cuando salió SOAP se vivió una época dorada de los servicios web. Aunque las primeras implementaciones eran lo que se llamaban WS1.0 y no soportaban casi ningún escenario avanzado, todo el mundo pagaba el precio de usar SOAP, ya que parecía claro que era el estándar que dominaría el futuro. Con el tiempo salieron las especificaciones WS-* que daban soluciones avanzadas, pero a la vez que crecían las capacidades de SOAP, crecía su complejidad. Al final, los servicios web SOAP terminan siendo un monstruo con muchas capacidades pero que en la mayoría de los casos no necesitamos.

Por su parte REST es simple. REST no quiere dar soluciones para todo y por lo tanto no pagamos con una demasiada complejidad una potencia que quizá no vamos a necesitar.

Uniform interface

Una diferencia fundamental entre un servicio web clásico (SOAP) y un servicio REST es que el primero está orientado a RPC, es decir, a invocar métodos sobre un servicio remoto, mientras que el segundo está orientado a recursos. Es decir, operamos sobre recursos, no sobre servicios.

En una API REST la idea de “servicio” como tal desaparece. Lo que tenemos son recursos, accesibles por identificadores (URIs). Sobre esos recursos podemos realizar acciones, generalmente diferenciadas a través de verbos HTTP distintos.

Así, en un servicio web clásico (SOAP) tendríamos un servicio llamado BeerService que tendría un método llamado GetAll que me devolvería todas las cervezas. La idea, independientemente de la tecnología usada para consumir el servicio web, es que se llama a un método (GetAll) de un servicio remoto (BeerService). Del mismo modo para obtener una cerveza en concreto llamaríamos al método GetById() pasándole el id de la cerveza. De ahí que se diga que están orientados a RPC (Remote Procedure Call – Llamada a método remoto).

Por su parte en un servicio REST la propia idea de servicio se desvanece. En su lugar nos queda la idea de un “recurso”, llamémosle “Colección de cervezas” que tiene una URI que lo identifica, p. ej. /Beers. Así, si invoco dicha URI debo obtener una representación de dicho recurso, es decir, debo obtener el listado de todas las cervezas.

Para obtener datos de una cerveza, habrá otro recurso (cerveza) con una URI asociada. Además, entre los recursos hay relaciones: está claro que una cerveza forma parte de la “Colección de cervezas” así que parece lógico que a partir de la colección entera (/Beers) pueda acceder a uno de sus elementos con una URI tipo /Beers/123, siendo "123" el ID de la cerveza.

Volvamos a nuestro servicio SOAP: para dar de alta una cerveza llamaríamos a un método "AddBeer" de nuestro "BeerService", y le pasaríamos la cerveza a añadir. En cambio, en nuestra API REST añadir una cerveza consiste en usar la URI de dicha cerveza, (p. ej. /Beers/456 si estamos añadiendo la cerveza con ID 456) usando POST o PUT como verbo HTTP y colocando los datos de la cerveza en el cuerpo de la petición. La URI para acceder a la cerveza con ID 456 es siempre /Beers/456 y es el verbo HTTP (GET, POST, PUT, DELETE,...) el que indica cual es la operación que deseamos hacer con esa cerveza.

Autor

Eduard Tomàs

Apasionado de la informática, los videojuegos, rol y... la cerveza. Key Consultant en Pasiona y MVP en #aspnet

Compartir

Comentarios

juanjose

25/4/2014
duda
una duda, y si no sé el ID de la cerveza que voy a agregar (como dice el ejemplo para agregar la URI sería Beers/ID) , quedaría con verbo POST y URI "Beers/" nomás ?

Leo

25/4/2014
RESTful
Podría realizarse indicando el recurso /Beers, sin especificar un ID, utilizando el verbo POST, indicando los datos de la cerveza en el cuerpo del request. Saludos!

nicolocodev

26/4/2014
RE: Duda
Hay gente que mapea los verbos HTTP a operaciones CRUD. Y cuando se llega a POST - PUT puede surgir la duda, hay quienes hacen la fácil y se van con POST -> Insert y PUT -> Update o viceversa :P. Pero hay mucho más de fondo.
Así de forma rápida (Y con lo poco que he visto) diría que: Si ya existe una URI del recurso, POST se puede usar para actualizar. Si no existe una URI del recurso, POST se usa para crearla, de la forma: post /recurso/ Y espera, en el response, la ubicación del recurso. Entonces si usas: post /recurso/{id_nuevo} al no existir debería retornar 404.
Y con PUT, podrías crear el recurso especificando la nueva URI y actualizar el recurso existente.

eiximenis

28/4/2014
Re: Duda
Para diferenciar entre cuando usar POST y PUT, lo mejor es irse a la especificación de HTTP. Allí se comenta que, a diferencia de POST, PUT debe ser idempotente. Resumiendo, una operación podemos decir que es idempotente si al ejecutarse dos o más veces seguidas no se observa diferencia alguna respecto a ejecutarla una sola vez.
Así, si asumimos que para añadir una cerveza usamos la URL /Beers:

1. Si en el cuerpo de la petición MANDAMOS el ID, entonces podemos usar POST o PUT: si una cerveza con dicho ID existe es modificada y en caso contrario es creada. Si se manda la misma petición DOS veces seguidas, la primera crea la cerveza y la segunda modifica (con los mismos datos) la cerveza creada anteriormente. Para un usuario no hay diferencia alguna entre el estado del sistema después de la primera llamada, y después de la segunda. Así pues la API es idempotente y por lo tanto podemos usar PUT.

2. Si en el cuerpo de la petición NO MANDAMOS el ID y a cada llamada se crea una cerveza nueva con un ID autogenerado, entonces DEBEMOS usar POST. Después de la primera llamada el sistema tiene una nueva cerveza y después de otra segunda llamada idéntica el sistema tendría dos cervezas nuevas. La API NO es idempotente y no podemos usar PUT.

Saludos!

David

03/5/2014
Diferencia SOAP y REST
Buenas.
Entonces la mayor diferencia entre estas dos tecnologías es que el SOAP se llama mediante funciones y el REST mediante URL´s?

Imagino que eso tendrá una explicación. Me pierdo un poco con el ejemplo ya que aparentemente se puede hacer lo mismo con las dos tecnoilogías pero de distinta manera.

Un saludo

clara

05/5/2014
DEMO
De csualidad no tienes a la mano una DEMO con REST? seria de mucha ayuda
gracias de antemano

iSVai

21/8/2014
Agradecimiento
Muchas gracias por tu artículo, está genial y me gusto mucho.
Saludos

mjguevara

18/1/2015
Muy Bueno
Man Genial y Muy Bien explicado.. Me quedo re claro!!!

Carles Tarahumara

15/4/2015
Muy bien
Muy bien. Todo correcto. Gracias!

Cristof

19/5/2015
Excelente articulo
Muchas gracias aclaro todas las dudas sobre REST

Martín

26/6/2015
Excelente artículo
Muchas gracias. Excelente artículo, muy clarificador. Saludos.

baddy

24/7/2015
Duda
Yo tengo una duda.
En mi caso tengo un servicio web rest y una aplicación web a parte del servicio. (están separadas)
Me gustaría saber como conectarlas; es decir como hacer, por ejemplo, un insert en la base de datos desde un servlet que llame al servicio web que está a parte.

Espero que me puedan ayudar.

sergio

01/8/2015
duda
Estoy por desarrollar tesis sobre servicios web,quiero implementar intercambio de información (formularios de salud a autoridades),y que se pueda enviar desde crm de centros de salud.investigue un poco WS* y ahora REST.Creo que me convendría la opción REST ya que solo son datos

Omar Lopez

21/9/2015
Cierto sabor
Buenas tardes desde Colombia, Servicios REST tiene por lo que lei cierto sabor a SQL, lo digo por los verbos INSERT, UP y OP que se mencionan. Mi dudA seria, tambien se llaman sentencias, en este caso no serian sentencias SQL sino sentencias REST. Gracias

Jorge

10/10/2015
Buenísima Explicación
Claro y Preciso. Muy buena explicación. Si fueras mujer me caso contigo :)

giovanny de arco

15/12/2015
Duda
La duda con esto, es que ahora como se debe llevar el desarrollo. Desde un principio crear una API REST y separar Backend y Frontend, o manejar el desarrollo habitual y luego si es necesario, crear una API REST.

jose

08/1/2016
no sirbe
no entiendo su description

Miguelon

16/1/2016
Excelente tuto.
Gracias por compartir con la comunidad.
Quito.- Ecuador
"La Mitad del Mundo"

PD: Me refiero a José el que dice que no sirve con B grande.
Para entender tienes que compreder. Si no entiendes -no- significa que no sirVe.
Por favor, respetar es una virtud, deberías conseguirla.

jocham miller

04/2/2016
especificacion SOA
ni idea :P

Héctor

09/2/2016
Excelente
Excelente articulo, muy claro, gracias

Juan

11/2/2016
Como hago en peticiones complejas
En mi caso, tengo un pequeño sistema web, y quiero separar el back a travez de un servicio web en este caso REST, bueno entiendo los de las URL, pero como haria la siguiente peticiones por ejemplo
1 Actualizar datos de un usuario
2 Actualizar estado a un usuario o varios, ya que hay un checkbox para elegir uno o varios
La primera (1) puede ser:
Método: PUT
URL: http://myrest/api/user/12
La segunda (2) puede ser:
Método: PUT
URL: http://myrest/api/user/change_state
¿Algo asi seria?
Porque tengo funciones mucho mas complejas, en mi antiguo sistema web uso codeigniter con arquitectura mvc, ahora he encontrado una libreria REST para codeigniter y estoy intentando comprenderla.
Otra cosa si bien dice que hay pasar mi usuario y contraseña por la url como haria en una petición GET?, porque ahi si estoy perdido.
Algo asi:?
Metodo: GET
URL: http://myrest/api/users/account/admin/password/1234
Saludos, espero sus respuestas

midesweb

01/12/2016
¿Comenzar el desarrollo con una API?
Para responder a Giovanny, sobre si conviene comenzar el desarrollo con un API REST o hacer un desarrollo tradicional y luego el API, pues todo depende.
Depende de muchas cosas, pero lo primero que me preguntaría yo es la necesidad a corto o medio plazo. Si ya sabes que en un corto espacio de tiempo de una app nativa para dispositivos o una progressive web app, porque el cliente ya te ha dejado claro que lo va a querer, entonces sería muy indicado comenzar con un API y basarte ya en él desde el principio. Te ahorrarás mucho trabajo porque no habrás de desarrollar muchas cosas dos veces, con y sin API.
Si no te han pedido hacer versiones de esa aplicación para otros sistemas, o el presupuesto está limitado, entonces no te interesará tanto desarrollar en base a una API, que da más complejidad.
De todos modos, si has desarrollado tu aplicación con una buena separación de responsabilidades, usando MVC o similares, el paso de construir el API será sencillo más adelante, porque generalmente lo que tendrás que programar es una capa de seguridad específica y generar las vistas que te devuelven JSON directamente.

caterina

19/5/2017
acciones en rest
Hola Eduard,
Estoy leyendo aqui y alla sobre la folosofia rest, la falta de estado, desacoplamiento entre en cliente y servidor etc. Todo esta claro, ahora mi duda es en cuanto al formato de las urls. Dices que RPC esta enfocado a servicios y rest a recursos.
perfecto, tengo un recurso, put lo crea, post recurso/id lo actualiza, delete lo borra, get lo recurpera, etc. Hasta aho todo en orden. Pero si yo necesito una accion especifica para un recurso, pongamos cambiar idioma a un recurso usuario, como seria mi url?

Un saludo y gracias por tu tiempo, Cate

Dazaeev

21/6/2017
ORDS
Muy bueno tu articulo, me sirvió de mucho de las dudas que traía.
Actualmente Oracle realiza servicios RESTful llamados ORDS y me a servido de mucho para realizaros, les recomiendo echarle una leída.
https://oracle-base.com/articles/misc/oracle-rest-data-services-ords-using-sql-developer

Diego mora

07/9/2017
Felicitaciones
Felicitaciones desde colombia. Muy buen articulo.

Lector

03/4/2018
Cerveza
Muy buen artículo, me ha quedado claro.
Eso sí, también me han entrado ganas de tomarme una cerveza... jajaja

Ricardo

02/6/2018
Completo
No había encontrado un sitio que explicara así de claro estos temas.

Cristian

01/7/2018
Perfecta explicacion
Gracias por la explicación, clarita y "al hueso". Saludos