La API de Twitter como estándar del microblogging

Pese a todos los posts que hablan de que el éxito del ecosistema de aplicaciones para Twitter implica que su API es genial y que debería ser adoptada como un estándar de API para microblogging y usada por todos en el mercado; la gente parece olvidarse que Twitter maneja su API, su negocio y su estructura de una manera bastante alejada de lo que es el Open Source y darle a una pieza de soft propietaria el título de API estándar es, cuando menos, estúpido.

Me gusta bastante el resúmen que hace Dare Obasanjo del tema:

The bottom line is that it isn’t as simple as saying “Twitter is popular and it’s API is supported by lots of apps so everyone needs to implement their API on their web site as well”. There are lots of ways to create standards. Crowning a company’s proprietary platform as king without their participation or discussion in an open forum is probably the worst possible way to do so.

Que algo tenga 50.000 aplicaciones creadas sobre su plataforma no implica que deba convertirse en un estándar de nada y mucho menos cuando ni siquiera la empresa está en la discusión de ese tema… ¿quien no sueña ser el dueño de un protocolo o formato estándar? Ahora, preguntenle a CoTweet lo bien que le cae el lanzamiento de Twitter Contributors y después hablamos de darle tanto poder a una empresa.

13 thoughts on “La API de Twitter como estándar del microblogging”

  1. Sinceramente no entiendo cual es el problema con que twitter sea una app con api y que ponga mas y mejores servicios en su aplicación web tratando de competir.
    Si al fin y al cabo, twitter es una empresa privada y hace de su culo un florero.

    Cualquier que desarrolle una aplicación que dependa de otra (twitter o la que sea), sabe que todo se puede ir al bombo desde el dia 0. Ahora, si lo sabes, y haces el desarrollo, luego no te quejes.

    ¿Qué pasa si un día google decide cerrar la API de Maps? ¿me tengo que re quejar y putear a los dioses por que mi negocio de un día para el otro se esfumó?

    1. No aparece tu nombre asi que no se quien sos pero el problema no es ese, es que se pida que la API de Twitter sea un estándar y se lo use como tal sin que siquiera la empresa este involucrada en las conversaciones; en cuantpo a lo otro escribí demasiadas veces sobre las empresas “parásitas” y sus problemas :)

  2. No digo que esté bien, pero en informática el 90% de los estandares son así. No es descabellado pensarlo y no sería malo hacerlo. No nos olvidemos que internet se basó en 2 estádares propiedad de Motorola e IBM (para las tramas) y unos cuantos mas de AOL y muy pocos no propietarios o mas bien casi ninguno…
    Es bueno que nos platiemos que esto es malo, pero hay un largo camino a que esto no suceda…. sino mirá cuantas cosas patentan por año las grandes compañias y veras que indefectiblemente lo que hagamos va a tener un conflicto d patentes con Microsoft, IBM o Nokia (preguntale a apple con el IPhone sino).
    Salu2

  3. Yo lo que no entiendo es qué le ves de cerrada a la especificación de la API de twitter.

    Estas mezclando conceptos. Vos decís “darle a una pieza de soft propietaria el título de API estándar” cuando Twitter nunca abrió ni exportó nada de código: ni ejecutables, ni módulos, ni nada. Y tampoco lo requirió para interactuar con su API

    Solo dijo “si querés sacar datos de mi db llamá a estos métodos remotos, llevate la información de tal o cual manera, y gracias por venir”. Que “pieza de soft” ves ahi?

    Ademas, para el intercambio de información eligieron una arquitectura de software preexistente, y muy popular ya desde antes (de otra manera): Las APIs RESTful, que fueron definidas por Roy Fielding en el 2000 (fuente Wikipedia: http://en.wikipedia.org/wiki/Representational_State_Transfer). Mas abierto que eso no hay.

    Lo único que “inventó” twitter fue OAuth, y encima, lo liberó: http://oauth.net/

    1. Gonzalo,
      si manana twitter te cierra el acceso a sus datos tu aplicacion muere. Abierto no es “respetar un estandar” es hacerlo abierto en serio y no creo que lo hagan ni que esten obligados a eso porque son una empresa.

      Pensar que “wow liberaron oauth y usan restful” es ser abierto es mirarlo solo aqui y ahora; no es algo para basar tu modelo de negocios en eso

      1. Si, pero lo que están diciendo es que hay que usar la especificación de Twitter como un estandard, no que todo tiene que pasar por el servidor de Twitter.

        Lo que vos decís es algo como: “Yo hice la especificación de POP3 y monté un servicio de mail. Un día decidí cerrarlo”, y que importa? si la especificación es libre y ya hay miles de implementaciones que no dependen de esa implementación inicial.

        Distinto sería decir “usemos la plataforma de twitter como estandar”. Eso si es cerrable.

        Una especificación no es “cerrable”, es una especificación y punto.

        De nuevo, mezclás conceptos.

      2. Gonzalo
        otra vez sos vos el que mezcla conceptos; estas hablando de soportar algo creado por una empresa darle estatus de estandar no involucrar a la empresa en la forma de acceder los datos y usar su arquitectura de API para todo lo que sea microblogging y casi todo lo qeu sea real time web… es ridiculo, no es abierto y una “especificacion” creada por una empresa y no liberada no es una especificacion que pueda estandarizarse por deecto porque existe algo llamado propiedad intelectual.

        O sea, vos usarias una especificacion que no es estandar para estandarizar un modelo de servicios en la web? Sinceramente te pediria (para que no creas que es que quiero tener razon yo) a fondo la nota de Dare Obasanjo que algo de plataformas y estandares sabe… antes de decir que confundo un estandar, una especificacion o una plataforma

        (Mas alla de que tu comentario otra vez vuelve a sacarme de contexto y responder solo lo que consideras acertado)

  4. Chicos soy bastante nueva en esto y no lo termino de entender!
    La API se descarga? de donde? o como se hace para programar algo que interaccione con twitter?
    espero sus respuestas!
    Gracias

Leave a Reply

Your email address will not be published. Required fields are marked *