A API do Twitter é um grande exemplo do por que é bom ter uma API que entrega bastante dados a cada requisição.

Se você possui dados valiosos na aplicação, acredite, as pessoas vão querer ler e mesclar esses dados dentro de novos aplicativos. Não adianta fazer nada, por que a questão é justamente “o que você deixou de fazer”. Eles fizeram.

O lado bom é que as vezes (muitas vezes) eles podem pagar por isso. Eles podem comprar a sua empresa só para agregar o valor do produto (dados). Podem te pagar pagar mensalmente pelos dados. E ainda existe o caso no qual a empresa pode recompensar quem usar sua API (se isso agregar valor de alguma forma ao produto, ou o tornar real).

Mas aqui tem um problema. Um problema que fica imperceptível aos olhos de pequenas aplicações mas que fica claro em robustas (pense no Twitter): são muitos dados para buscar e muitas requisições para responder.

No caso do Twitter, mesmo quando eles haviam entendido a aplicação como um sistema de entrega de mensagens assíncronas e então resolvido os problemas com leitura/escrita e locks na base de dados, faltava-lhes algo. Eles sabiam que estavam somente começando a enfrentar o problema de escrita/leitura de uma grande quantidade de dados ao mesmo tempo. Tanto que compram logo o Summize que tinha um estrutura e melhor experiência para lidar com esse tipo de problema.

Particularmente eu acho muito mais importante entender ferramentas como o Hadoop e/ou CouchDB do que depender da quantidade de memoria da maquina de MySQL, de sharding ou de cluster. E provavelmente foi isso que o pessoal do Twitter fez, provavelmente era isso que o Summize tinha e vendeu: conhecimento em sistemas distribuídos para web.

Mas voltando ao assunto principal: API.
Se sua aplicação vai ser digamos que o novo Submarino. Digamos que no meio da crise você consiga até comprar a B2W (empresa responsável pelo Submarino). Por que você deveria se preocupar em fazer uma boa API?

Ah… é um e-commerce. Não é nenhuma dessas aplicações novas da Web. Pra que RSS? Pra que API?

Eu digo por que: se você não fizer um RSS ou uma API, as pessoas irão partir para ignorância.
Repito: se você está expondo dados de alguma forma na web, não tem como impedir que eles não sejam extraídos para uma outra aplicação. Screen Scraping é uma arte antiga e fácil.

E aqui você tem um grande problema: como você não planejou esse tipo de acesso (bots acessando muito frequentemente o seu servidor), você vai ter problemas decorrentes da falta de planejamento.

Que eu saiba somente um grande (e antigo) player da Web brasileira está desenvolvendo uma API para um grande estoque de produtos. Essa é a chance da sua solução de e-commerce ter algo competitivo com esses caras: faça uma API rapidamente. Procure por algum protocolo aberto para o seu modelo de API (API de fotos, API de produtos, etc) e desenvolva essa área. Se você fizer algo, por favor deixe-me ficar sabendo. Eu quero o maior número de API de produtos que vocês conseguirem me dar e prometo que retribuo

Só para reforçar a importância que uma API tem, dê uma olhada na qualidade da documentação que o Twitter disponibiliza para sua interface de aplicação. Reparem na quantidade de dados que é possível retirar com uma só requisição… totalmente excelente!

Desculpas para quem leu a versão zuada que foi no RSS antes. Publiquei antes de assar