30
Sep

Explicando REST a mi madre

CB009957Si mamá, desde hace ya un buen tiempo, cuando vienes a visitarme a casa, no paras de leer en la pantalla de mi ordenador, en los papeles que tengo por ahí sueltos,  eso de REST. Y como no acabas de creerte que el término no tiene nada que ver con colchones, voy a intentar explicártelo.

Puedes encontrar artículos en la web que describen REST en castellano de pe a pa, e incluso completísimos tutoriales sobre como montar tu primera aplicación REST con java, pero quizás todo sea demasiado teórico y complejo para alguien que, como tú, busca una primera aproximación y no tiene porqué tener necesariamente mucha idea de Web Services, SOA o HTTP. Voy a intentar explicártelo muy claro y con ejemplos, como a ti te gusta.

Tranquila mamá, no te sientas mal por no tener muy claro esos conceptos. Hay muchos arquitectos de software y desarrolladores que tampoco los tienen. A lo mejor a ellos también les interesaría escuchar todo esto que te cuento. Es fácil, creo que en menos de 5 minutos tú y ellos os habréis hecho con ello.

Lo primero que tienes que tener claro es que REST no es una tecnología sino una arquitectura. Para que lo entiendas, no es algo que solucione cosas sino una forma de diseñar algo que solucione cosas. ¿Y qué tiene de especial esta arquitectura para que todo el mundo hable de ella? Intentaré explicártelo.

  1. Diseñas tu aplicación exponiendo recursos no funcionalidades. Sí, ya no programo páginas web que tengan direcciones como www.mipagina.com/crearCosa o www.mipagina.com/consultarCosa. Ahora sólo tengo www.mipagina.com/cosas o www.mipagina.com/cosas/12345/atributos. Sí te das cuenta, es como si tuviera mis recursos ordenados en directorios. Y sí, sé lo que te estás preguntando: si sólo hay un www.mipagina.com/cosas ¿cómo sé si mis usuarios intentan crear una cosa o simplemente consultarla? Ahora te explico, ten un poco de paciencia.
  2. Utiliza los métodos del protocolo HTTP de manera explicita. HTTP es un protocolo de comunicación que hace que Internet funcione. ¿No te has dado cuenta de que cuando escribes una dirección en el navegador pone http:// por delante de la dirección? Bueno, pues eso es porque te estás comunicando mediante ese protocolo. Lo que no tanta gente sabe, incluidos muchos programadores, es que el protocolo HTTP tiene un montón de métodos definidos en su especificación: GET, POST, PUT, DELETE… y que cada uno de ellos tiene un propósito específico aunque, a veces, te reconozco que los desarrolladores nos lo saltamos a la torera.  No te suena de nada ¿verdad? Eso es porque la mayoría de los navegadores utilizan el método GET por defecto en las peticiones HTTP, excepto que le indiquemos especificamente otra cosa en nuestras páginas web. Así , cuando escribimos el nombre de una página en la barra de direcciones de un navegador, la invocamos con el método GET. ¿Que por qué te he soltado este ladrillo que no te interesa? Espera un poco, ya verás como todo empieza a encajar.
  3. Mapea los métodos del protocolo HTTP a las operaciones a realizar sobre un recurso. Fíjate que bueno, si te conectas a un recurso -una página web, para que lo entiendas- invocando el método GET, por ejemplo, yo sé que es lo que quieres porque el método GET se utiliza para consultar un recurso. Del mismo modo, al resto de los métodos principales de HTTP se les mapea una operación específica. Así, POST se utiliza para crear un recurso, PUT para actualizarlo y DELETE para borrarlo, evidentemente. Si, por ejemplo, solicitas la página  www.mipagina.com/cosas con el parámetro id=2345 y el método GET, mi aplicación REST te devolverá la cosa con id=2345. Sin embargo, si repites la misma solicitud con el mismo parámetro pero con el método DELETE lo que  conseguirás es borrar la cosa con id=2345.  ¡Tacháaan! ¿A que ahora parece todo más claro?
  4. Transfiere XML, JSON o XTHML. No te voy a calentar la cabeza mamá explicándote qué es cada cosa. Confía en mi. Basta con que sepas que son cosas que se pueden consumir e interpretar desde un navegador y convertir en una de esas bonitas páginas web que tanto te gustan. Sólo para que lo sepas, cuando te digo que te devuelve una cosa, me refiero a que te devuelve algo como esto:
<cosa>
    <id>2345</id>
    <nombre>cosa misteriosa</nombre>
</cosa>

Sé que tendrás algunas dudas. Creo que podré adivinar alguna de ellas :)

  • ¿Cómo le indico eso del id? ¿Sólo puedo mandar un parámetro? Y lo de los métodos HTTP ¿Cómo se cambian? Bueno, a ver, el id es un parámetro que envías en tu petición. Y, claro, puedes mandar todos los que quieras. Si lo piensas bien, cuando rellenas un formulario en una página web no estás haciendo más que mandar un montón de parámetros -uno por cada campo del formulario- sin límite alguno. Usando REST no haces mas que navegar así que, SÍ, puedes enviar lo que quieras. Respecto a lo de cambiar el método HTTP a utilizar bueno… eso no es tan sencillo. No vas a poder hacerlo directamente desde tu navegador pero, los programadores de páginas HTML sí tienen la posibilidad de hacerlo. Si llegas a una página web diseñada para utilizar con una aplicación REST y, por ejemplo, ves un botón “Eliminar Cosa“, seguro que vas a hacer una petición con el método DELETE
  • ¿Y si no le paso ningún parámetro? No pasa nada. Si, por ejemplo, haces una petición GET a www.mipagina.com/cosas sin pasar ningún parámetro, probablemente conseguirás que una aplicación REST te devuelva un montón de enlaces a todas las cosas que esten relacionadas con dicho recurso. Por ejemplo, una lista de cosas (www.mipagina.com/cosas/0001, www.mipagina.com/cosas/0002…). Si lo piensas bien todo lo que te devuelve son a su vez enlaces REST que puedes reutilizar haciendo nueva petición con el método que te interese contra dichos enlaces. ¡Genial! ¿Verdad?
  • ¿Y todos los recursos implementan todos los métodos? Pues, realmente NO. De hecho, hay otro método de HTTP, OPTIONS, cuya finalidad es obtener una lista de los métodos soportados por un recurso. A lo mejor, el programador de una aplicación REST quiere permitirte consultar una determinado información pero no quiere que la actualices.
  • Y entonces ¿cualquiera puede borrar cosas de tu aplicación? No. Puedes identificar a tus usuarios con los métodos de autenticación que te proporciona cualquier servidor HTTP o incluso utilizar cosas más sofisticadas.  No te preocupes, puedes conseguir que sólo acceda a tu aplicación REST quien tú quieras.

Como ya te he dicho REST sólo es una arquitectura, no una tecnología. Tienes que evaluar bien si te interesa o no utilizarla. Si te interesa conocer cuáles son algunas de sus ventajas, te explicaré alguna de las más importantes:

  • El método HTTP GET y el cacheo. Muchos proxies y firewalls -ordenadores que gestionan una red- suelen cachear las peticiones GET. Que, ¿qué es eso de cachear? Pues guardarse una copia de la página que solicitas con tu método GET y, si otro ordenador de tu misma red solicita la misma página, devolver esa copia mucho más rápido que si tuviera que obtener la página de nuevo.
  • No utiliza estado de sesión. A ver como te explico esto… ¿recuerdas cuando me pediste que te enseñara a comprar por Internet y estuvimos comprando libros? Esos libros se iban acumulando en un carrito de la compra y, al final, pagamos con tarjeta de crédito. Bueno, ese carrito de la compra existía porque la página web nos identificó durante toda nuestra sesión de trabajo y, es genial. Lo que pasa es que, al final, somos muchos los que compramos libros y eso puede acabar sobrecargando los servidores donde se alojan las páginas web. Cuando 5 están comprando libros no hay problema pero, cuando son 5000… la cosa cambia. El hecho de que REST no mantenga estado de sesión quiere decir que en nuestras peticiones de recursos y en las respuestas del servidor tiene que viajar toda la información necesaria. Nada se guarda en la memoria del servidor.
  • Puedes distribuir una API completa de tu aplicación en un fichero de javascript. Mmmm… para que lo entiendas de una forma sencilla ¿conoces Facebook, no?. Bueno, pues lo bueno de  Facebook, lo que ha hecho que triunfe tanto es que ha posibilitado que terceros creen aplicaciones y las incrusten en la página. Casi todas esas aplicaciones te permiten interactuar con tus contactos de Facebook, pero dichas aplicaciones no tienen acceso directo a la BBDD de la página web, sino a una API, un conjunto de utilidades, que proporciona Facebook y que permiten acceder, por ejemplo, a los amigos del usuario que está ejecutando la aplicación. Créeme, eso es una aplicación REST como una casa. ¿Te imaginas que Facebook tuviera que distribuir por ahí la ruta de acceso a su BBDD? ¿Te imaginas los problemas de seguridad y escalabilidad que supondría?

En fin mamá, que REST está muy bien, pero es una manera más de solucionar las cosas, ni más ni menos. Por ejemplo, no tengo muy claro que fuera la arquitectura más adecuada para ese ejemplo que te he puesto del carrito de la compra, aunque sí para muchos otros supuestos.

La gente está muy ilusionada con el tema, sobre todo como una apuesta para conseguir de una manera sencilla, rápida y flexible la interoperabilidad entre distintas aplicaciones escritas en distintos lenguajes. Antes todo el mundo pensaba que los webservices eran el único medio válido para conseguir esto de una manera eficiente pero, ahora, hay bastante gente que lo pone en duda porque, la verdad, la especificación donde te explica cómo implementarte por entero un webservice, cómo publicarlo y cómo consumirlo es… un poco dura y pffff… ¡no creo que consiguiera explicártela en 5 minutos como he hecho con esto del REST! Y eso es lo bueno de esta arquitectura. Mamá, si tú has conseguido entenderlo, creo que cualquier desarrollador lo hará.

Artículos relacionados:

  1. HTTP Access Control: programando REST de VERDAD La mayoría de los que hablan de REST son un...