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

]]> http://sixservix.com/blog/david/2009/09/30/explicando-rest-a-mam/feed/ 4