Pero, a veces, el destino es caprichoso y te lleva por caminos insospechados. Te encargan que hagas un prototipo en Android y, cuando te quieres dar cuenta, estás RESTificando tu aplicación para conectarte a ella, como Dios manda, desde tu zapatófono con el sistema operativo de Google.

Y, cuando te pones en serio a implementar algo, pasa lo de siempre: que te manchas las manos y nada es tan limpio como parece. Perdí al menos un par de horas intentando descubrir por qué el REST del demonio no funcionaba como se supone que debía hacerlo.

Así que decidí escribir un artículo técnico. De esos que dan prestigio y hacen que no te etiqueten exclusivamente como un businessman. Sí, de esos artículos que no lee ni mi mujer. Eso sí, ya que no lo iba a leer nadie, lo he escrito a mi manera, nada de ladrillos incendiarios como los que se gasta el maligno y vehemente Dr. Arranz.

Si quieres saber qué es eso del HTTP Access Control y por qué debes tenerlo en cuenta cuando desarrolles en REST, sigue leyendo.

Banda Sonora del artículo: Cage the Elephant – In One Ear

EL CONTEXTO

Con una aplicación legacy -y una aplicación en Struts 1 lo es-, lo más lógico es recurrir a un framework que te ayude a implementar REST sin tener que entrar como un elefante en una cacharrería ni reinventar la rueda. Según Google, tenía dos opciones básicas: Jersey, la implementación de referencia de Oracle/SUN y Restlet, el voluntarioso esfuerzo que da de comer a Noelios Technologies.

La introducción de la API 2.4.1 de RESTLET es muy LOL :D

Jersey debe ser una maravilla, pero ha debido de ser el último framework en sufrir el rebranding de Oracle y no me funcionaba ni un solo enlace a la documentación. Así que la elección estaba clara.

Lo malo de Restlet es que, el cambio de la versión 1 a la 2 ha sido más traumático que encontrarte a tu abuela desnuda en la ducha, así que todos los ejemplos que encontraba sobre cómo utilizar Restlet valían lo mismo que un billete de 7 euros.

Algunos cambios eran sencillitos, como el rename de Resource a ServerResource, pero otros -el constructor de ServerResource ya no recibe como parámetros un Request y un Response sino que la factoría de creación los inyecta después de instanciar el objeto- te obligaban a hacer lo que hacen los hombres de verdad: remangarse la camisa y tirar de API.

Implementé el mejor ejemplo que encontré, adaptándolo para que funcionara con Restlet 2, incrustado en mi aplicación legacy, y creé un HTML+JavaScript (del bueno) independiente, con un formulario básico que me permitiera indicar la URL, parámetros y método HTTP que quisiera probar. Un figura, ese soy yo.

EL MURO DE CEMENTO

Empiezo a probar mi implementación a través de mi cliente  y la cosa parece que funciona: consigo controlar el flujo de la aplicación -hasta un catch-all-, recoger parámetros y devolver mi Response… pero, cuando llega a mi cliente, un flamante Firefox 3.6.2,  el HTTP Status, ese que te indica que todo ha ido como la seda o que has metido la pata, es un cero patatero. ¿¿¿ Cero ??? WTF ???

Bueno… el HTTP Status es básico para validar las cosas van bien, pero podría llegar a prescindir de él. Ya validaré los datos del Response, a lo Pancho Villa, en cliente, pero es que… ¡tampoco llegan los datos! Ostras, esto ya es más grave.

Se me enciende la bombilla y pienso “claro, eso es porque no indicas el status antes de devolver la Response desde tu aplicación de servidor” y me pongo a hacer idioteces como esta en Restlet:

setStatus(Status.SUCCESS_OK);

¡Pero tampoco funciona! ¡Maldita sea! Y, lo peor de todo, es que, cuando llamaba a los servicios directamente por invocación desde la barra del navegador en vez desde mi HTML+JavaScript (del bueno) independiente, todo funcionaba bien… ¬¬

EL PROBLEMA

Después de comprobar unas 20 veces que tenía todo BIEN y, aún así, todo funcionaba MAL, me dio por googlear ‘HTTP Status ==  0′ y la explicación que encontré era tan simple que no podía creerlo. Lo más increíble de todo era el párrafo que decía “... y no te funcionará en otro navegador que no sea Explorer“. Así que,  me esforcé por recordar cómo podía abrir el Internet Explorer, ejecuté mi cliente HTML+JavaScript (del bueno) con él y… voilà! El navegador no solo recibía un Status 200 aka “todo ha ido fino Pochettino” sino que me pintaba, con mi AJAX de todo a 100, los datos de respuesta del servidor.

Al final, todo era una cuestión de seguridad… y de cross-site scripting.

Si os leéis este textazo técnico de Mozilla, aprenderéis que, por defecto, Firefox implementa una restricción de seguridad que impide el cross-site request o, lo que es lo mismo, que un recurso de un dominio A haga una petición de un recurso del dominio B.

En mi caso, mi cliente HTML estaba alojado en mi disco duro, mientras que el recurso que solicitaba por REST era servido por  un TOMCAT en local … pero  evidentemente en dominio diferente para el navegador.

La solución consiste en incluir una cabecera especifica en la HTTP Response que se envía de vuelta al navegador: Access-Control-Allow-Origin

Mediante esta cabecera, desde el servidor podemos avisar al navegador de qué dominios están autorizados para solicitar recursos de nuestro sitio. Si queremos permitir el acceso a nuestra API REST desde cualquier dominio, como en mi caso, tendremos que darle el valor “*” a dicha cabecera.

LA SOLUCIÓN

Soy un looser y no sé cómo incrustar un snippet de GitHub en el WordPress. No me funciona ni un plugin !!! O_o

El problema es que con Restlet no manejamos directamente las cabeceras HTTP, sino que estas se manejan encapsuladas en wrappers propios de la aplicación.

Para poder escribir esta cabecera, debemos recuperar este wrapper en forma de objeto Form y añadir la cabecera directamente.

Para evitar hacer esto en cada método (GET, POST, PUT…) de nuestro ServerResource, he sobrescrito el método do Init() que se ejecuta cada vez que se instancia el objeto.

Es evidente que podríamos hacer una refactorización inmediata y hacer que nuestros ServerResources (realmente, los recursos REST que exponemos gracias a Restlet) no extiendan directamente de esa clase abstracta sino de una implementación propia que sobrescriba el doInit() para todos.

Como soy un auténtico perdedor, no he conseguido copiar el fragmento de código que había colgado en GitHub, pero aquí os dejo el enlace.

Queda mucho por hablar de cómo juguetear, de verdad, con REST (autenticación, el preflighted o verificación previa, etc), pero por hoy es suficiente. Ya os habéis tragado un articulazo de casi 1200 palabras.

DISCLAIMER: La verdad es que no hace falta nada de esto para trabajar con mi aplicación de Android. En Android, pondría un cliente de Restlet y se comunicaría con mi aplicación por conexión directa, nada de navegador.

También es importante que sepáis que mucha gente no utiliza el Access-Control-Allow-Origin con valor *, sino que gestionan una lista blanca de dominios autorizados. ¿A alguien le suena el registro de dominio para utilizar las APIs de Google?

Artículos relacionados:

1. Explicando REST a mi madre Si mamá, desde hace ya un buen tiempo, cuando vienes...

Si eres un desarrollador y piensas “A mí plin Paquirrín. Eso no tiene nada que ver conmigo“, disculpa si te lo digo con crudeza: eres un looser. Saca durante un instante la cabeza de Hibernate y Spring porque te están impidiendo ver el sol :).

Twitter no es sólo una página güel, no es sólo un “Facebook pero en pequeño” ni la última tontuna de los modernos de turno. Twitter es una plataforma y, como tal, debes aprender a desarrollar para ella. Porque nunca sabes cuándo te puede venir bien utilizarla y porque, créeme, a tus clientes les puede parecer más o menos interesante que utilices Toplink, Hibernate o SQL con escoplo y martillo, pero es probable que alguno te pida algo para Twitter. ¿Quieres quedar como un zocolotroco desfasado o como un gurú del Interné? Invertir 5 minutos en la lectura de este articulo separa una cosa de la otra.

¿UNA PLATAFORMA?

Si amigo, Twitter  es una plataforma. Y ¿por qué es una plataforma? Porque te proporciona una completa API REST para que utilices todos los servicios que ofrece desde tu propia aplicación de una forma sencilla y gratuita.

Ésta es la clave del éxito de páginas como Twitter o Facebook, su espíritu de auténticas plataformas donde terceros desarrollen sus propias aplicaciones.

Sí, twitter es una plataforma, pero NO de este tipo...

Sí, Facebook está muy bien, pero ¿alguien puede imaginárselo sin los cientos de juegos del tipo “¿Quien es el más listo de tus amigos?” o “El Granjero que llevas dentro”? ¿Y sin las miles de aplicaciones para enviar osos amorosos o bocatas de calamares a tus amigos? La genialidad de Twitter y Facebook es conseguir que terceros desarrollen, sin coste alguno para ellos, y hagan crecer y enriquezcan la plataforma. ¿Que esos terceros también se lucran? “Genial”, piensan ellos, así ganamos todos.

Por poneros un ejemplo de lo que NO es una plataforma, tenemos a nuestro propio clon local y reggaetonero de Facebook: el Tuenti. No hay un enlace a “Desarrolladores” o a “API” en la web de Tuenti. Ellos se lo guisan y ellos se lo comen. Vale, veremos como les va, pero, de momento, van cuesta abajo y sin frenos.

VALE ¿CÓMO EMPEZAMOS?

Lo primero que tienes que hacer es dar de alta una cuenta en Twitter. ¿Por qué? Porque con esa cuenta podrás registrar tus aplicaciones. Necesitamos registrar las aplicaciones en Twitter para utilizar OAuth como medio de autenticación.

La verdad, podríamos pasar del OAuth para hacer nuestra primera aplicación, pero ya que nos ponemos a juguetear con Twitter, mejor aún si aprendemos algo nuevo y ¡Carambolas! ¡El OAUth mola! :)

Key y Secret de Oauth que se obtiene al registrar la aplicación

Hablar de OAuth no es el objetivo de este post, pero lo describiré de un modo breve. Básicamente, el método de autenticación OAuth se basa en que, el usuario no se autentica en tu web mediante usuario y contraseña sino que lo hace en la plataforma que gestione la autenticación (por ejemplo, Twitter) y ésta te da un token de autenticación que es el que tu guardas y utilizas para comunicarte en el futuro con dicha plataforma.

Evidentemente, ese token vale para y SÓLO para tu aplicación. Ahí está el truco. Y, para que la plataforma sepa qué aplicación es la que está requiriendo autenticación, te proporciona unas claves que tú envías cuando haces las llamadas de validación de claves. Twitter, al registrar una aplicación, te da las claves necesarias para  trabajar con OAuth desde tu aplicación.

Ah, una última cosa: como desarrolladores, Twitter nos asigna una serie de cuotas para el uso de sus servicios (recordemos, gratuitos). En concreto, 150 llamadas a la API por hora y por IP/Cuenta de Usuario.

Si nos hemos emocionado con todo esto de las plataformas y tenemos pensado desarrollar La Madre de todas las Aplicaciones de Twitter, podemos solicitar en este enlace que nos amplíen la cuota hasta 10.000 llamadas a la hora, pero, de momento, no creo que sea necesario.

Ahora sí, tenemos todo lo que hay que tener para empezar a desarrollar nuestra primera aplicación para Twitter.

MANOS A LA OBRA

Como hemos comentado antes, la API para trabajar con Twitter es una API REST. Si no sabes lo que es REST, aquí tienes un excelente artículo :P sobre el tema, pero, en cualquier caso, no te preocupes. No te hace falta saber absolutamente nada de REST porque utilizaremos uno de los envoltorios Java que ya están creados. Si eres capaz de invocar un System.out.println(), serás capaz de trabajar con esta API.

En la propia página de librerías Twitter tienes un montón de frameworks ordenados por lenguaje. Voy a centrarme en las opciones que hay para Java, el lenguaje que utilizo y amo, y dentro de éstas, en Twitter4j. Más que nada, porque es la que mejor diseño y documentación tiene.

Vamos a ir describiendo, paso por paso, cómo crear nuestra aplicación java/twitter:

1. Descargamos la librería de la web de Twitter4j. En un fichero zip, encontraremos tanto la librería en sí como el resto de librerías que necesita para funcionar y, si lo preferimos, un fichero pom de Maven con todas las dependencias.
2. Instalamos el conjunto de librerías, tanto Twitter4j como aquellas de las que depende, haciéndolas accesibles a nuestro classpath
3. Nos crearemos la clase BoniTwitterTest donde copiaremos el siguiente código:

[java autolinks="false" classname="BoniTwitterTest" collapse="true" firstline="1" gutter="true" htmlscript="false" light="false" padlinenumbers="false" smarttabs="true" tabsize="4" toolbar="true"]

import twitter4j.Twitter;
import twitter4j.TwitterException;
import twitter4j.Status;
import twitter4j.http.RequestToken;
import twitter4j.http.AccessToken;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.Hashtable;

public class BoniTwitterTest {

private static Hashtable<String, AccessToken> almacen = new Hashtable<String, AccessToken>();

public static void main(String args[]) throws Exception {

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
while (true) {
Twitter twitter = getTwitter();
System.out.println("Introduzca su nombre de usuario:");
String usuario = br.readLine();
AccessToken accessToken = almacen.get(usuario);
while (accessToken == null) {
RequestToken requestToken = twitter.getOAuthRequestToken();
System.out.println("Visita la siguiente página web y autoriza el acceso a tu cuenta:");
System.out.println(requestToken.getAuthorizationURL());
System.out.print("Una vez visitada, introduce el PIN y pulsa enter:");
String pin = br.readLine();
try {
if (pin.length() > 0) {
accessToken = twitter.getOAuthAccessToken(requestToken, pin);
} else {
accessToken = requestToken.getAccessToken();
}
// Se guarda el token de autenticación para utilizar en un futuro
storeAccessToken(usuario, accessToken);
} catch (TwitterException te) {
if (401 == te.getStatusCode()) {
System.out.println("No ha sido posible obtener el token de autentiación");
} else {
te.printStackTrace();
}
twitter = getTwitter();
}
} // FIN del bucle WHILE que asegura la autenticación
twitter.setOAuthAccessToken(accessToken);
System.out.println("Introduzca su nuevo estado de Twitter o NADA si desea salir y pulse ENTER:");
String status = br.readLine();
if (status == null || status.length() == 0) {
System.out.println("Gracias por usar la aplicación. Adios !!!");
System.exit(0);
} else {
Status tstatus = twitter.updateStatus(status);
System.out.println("Se ha actualizado con exito el estado a [" + tstatus.getText() + "]");
}

} // FIN del bucle WHILE principal de la aplicación

}

/**
* Este metodo nos devolvera una instancia del objeto Twitter con la OAuyth Key y el OAuth Secret configurados
* @return una instancia del objeto Twitter
*/
private static Twitter getTwitter() {
Twitter twitter = new Twitter();
twitter.setOAuthConsumer("OAuth Key", "OAuth Secret");
return twitter;
}

/**
* Guarda el token de autenticación de un usuario en una Hashtable
* @param usuario el ID de usuario que servira como clave de guardado
* @param at el token de autenticación
*/
private static void storeAccessToken(String usuario, AccessToken at) {
System.out.println("USUARIO TWITTER " + usuario);
System.out.println("TOKEN " + at.getToken());
System.out.println("TOKEN SECRET " + at.getTokenSecret());
almacen.put(usuario, at);
}

}[/java]

4. Tenéis que sustituir las cadenas de texto  ‘OAuth Key‘ y ‘OAuth Secret‘ por las claves que os haya proporcionado Twitter al registrar vuestra aplicación.
5. ¿Que qué hace este código? Pues, básicamente, comprobar si tenéis el token de validación de un usuario en el sistema y, si no lo tenéis, pediros que visitéis una web para obtener un código o PIN de autorización que demuestre que el usuario ha autorizado a tu aplicación a acceder a la API de Twitter en su nombre.
   

   Ésta es la web en la que el usuario autoriza o no a tu aplicación para trabajar en tu nombre en Twitter

   

   Éste es el PIN que te proporciona Twitter para que introduzcas en tu aplicación

6. Una vez que introduces el PIN, obtienes el token de autenticación y ya puedes solicitar los servicios de Twitter en nombre del usuario autenticado.
7. Nuestra pequeña aplicación, se limitará a solicitarnos el status con el que queremos actualizar la cuenta de Twitter del usuario autenticado.
8. Si actualizamos el status con la frase ‘Actualizando el Estado de Twitter desde mi propia aplicación Java‘ podremos comprobar como en la cuenta de Twitter del usuario -en este caso, yo- el estado se ha modificado:
   

   Fijaos en que pone que el estado se ha modificado desde 'Prueba David' el nombre de mi aplicación registrada

Si accedéis a la API de Twitter desde una aplicación web, podréis redirigir el flujo de la aplicación a la página de autenticación y configurar dicha página para que invoque una de vuestras páginas mediante callback. Mola ¿verdad? Se autentican en Twitter y continúan en tu aplicación proporcionándote el PIN de autenticación de paso.

Evidentemente esta aplicación es una chorrez como un piano, pero es un ejemplo claro y sencillo sobre cómo registrar una aplicación en Twitter, cómo autenticar a un usuario mediante OAuth y cómo manejar su pool de servicios en nombre de ese usuario. A partir de aquí, enriquecer y hacer crecer esta mini aplicación, depende de vosotros. Seguro que se os ocurren un montón de ideas, simplemente estudiando las posibilidades de la API, pero os voy a proponer algo: ¿No creéis que sería interesante para un departamento de marketing una aplicación que buscara menciones de los productos de una compañía en los tweets de la gente y que guardara los IDs de la gente para, posteriormente mandarles tweets de respuesta con ofertas o comunicados? Yo, al menos, conozco a más de un gurú del marketing muuuy interesado :)

Espero que este humilde tutorial os haya servido de ayuda y os anime a crear la nueva killer application de esa pequeña gran plataforma llamada Twitter.

Algunos links de interés

API REST DE TWITTER: http://apiwiki.twitter.com/Twitter-API-Documentation

API JAVA TWITTER4J: http://yusuke.homeip.net/twitter4j/en/javadoc/index.html

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...