Entre los mayores logros de Twitter se encuentra el haber ofrecido desde el comienzo una API muy funcional. Esto permite que todos sus datos sean compartidos por este medio, facilitando el surgimiento de proyectos que dejan ver los distintos datos del servicio en m?ltiples formas.

Lo primero que podemos decir es que la API de Twitter se desarrolla a partir del estilo REST (Representational State Transfer). Este se distingue del XML-RPC por ser un dise?o que carece de estados y cuyos m?todos se pueden encontrar en una ?nica URL. Sacando algunos m?todos de car?cter p?blico, todo el resto necesita de las credenciales a las que accede un usuario registrado (aclaremos que la autentificaci?n se hace a trav?s de HTTP).

Ahora bien, la llamada a estos m?todos se realiza por medio de peticiones POST, GET o HTTP, de acuerdo a la ocasi?n. En el caso de los m?todos que devuelven datos, es posible pedirlos bajo el formato RSS, XML JSON o ATOM. Lo que s? debemos hacer cuando hacemos llamadas a los m?todos es no olvidar chequear el HTTP Status Code que nos devuelve el servidor de Twitter. En caso de recibir un c?digo distinto, podemos saber que algo no ha funcionado (el significado del c?digo recibido va a depender, obviamente, del m?todo al hayamos llamado).

Otra cosa que siempre tenemos que tener presente es que hay un l?mite m?ximo de 70 peticiones por hora para cada usuario. Este l?mite representa una de las dificultades m?s grandes cuando trabajamos con la API, ya que hay que lograr optimizar las llamadas para no quedar afuera muy r?pido. Sin embargo, tanto los m?todos p?blicos como los que necesitan una petici?n POST no son tomados en cuenta respecto a este l?mite.

No se pierdan los pr?ximos art?culos sobre esta sensacional aplicaci?n!