Développer / Tester des applications Twitter sans claquer l'API

Question

Je travaille actuellement sur une application qui fonctionne avec Twitter, mais lors du développement / du test (en particulier des parties qui ne reposent pas sur de vraies données Twitter), j'aimerais éviter de frapper constamment l'API ou de publier des fichiers indésirables. tweets.

Existe-t-il une stratégie générale utilisée par les utilisateurs pour simplifier l’API (mise en cache mise à part)? Je pensais lancer ma propre bibliothèque qui intercepterait essentiellement les demandes sortantes et renverrait des réponses fictives, mais je voulais être sûr de ne rien manquer d’évident en premier.

Answer 1

Je commencerais probablement par me moquer des parties spécifiques de l'API dont vous avez besoin pour votre application. En fait, cela pourrait vous forcer à concevoir un design plus propre pour votre application, car il vous obligerait plus ou moins à réfléchir à votre application en termes de "quoi". il faut faire plutôt que "comment" il devrait le faire.

Par exemple, si vous utilisez l'API de recherche Twitter, votre application ne devrait probablement pas se soucier de savoir si vous utilisez ou non l'option de format JSON ou Atom. La possibilité de rechercher sur Twitter à l'aide d'une requête donnée et d'obtenir des résultats représente la fonctionnalité souhaitée. Vous devez donc vous moquer de l'API à ce niveau d'abstraction. Le format de sortie n’est qu’un détail de la mise en oeuvre.

En moquant l'API en termes de fonctionnalités plutôt qu'en termes de détails d'implémentation de bas niveau, vous pouvez vous assurer que l'application fait ce que vous attendez avant de vous connecter réellement à Twitter. À ce stade, vous avez déjà vérifié que l'application fonctionnait comme prévu. Il ne vous reste plus qu'à écrire le code pour effectuer les demandes REST et analyser les réponses, ce qui devrait être assez simple, pour ne pas aboutir. frapper Twitter avec beaucoup de données indésirables à ce moment-là.

Answer 2

La mise en cache est probablement la meilleure solution. De plus, je crois que l’API est limitée à 100 demandes par heure. Alors peut-être créer une fonction qui continue à compter chaque demande et quand elle approche les 100, cela dit, OK, toutes les 10 demandes d'API, je vais extraire les données. Ce ne serait pas difficile à définir, probablement une fonction de dégradé qui réduit les effets lorsque vous approchez de la limite.

Answer 3

J'ai utilisé Tweet #, il met en cache et devrait faire tout ce dont vous avez besoin, car il contient 100% de l'API Twitter, puis quelques-uns ...

http: / /dimebrain.com/2009/01/introducing-tweet-the-complete-fluent-c-library-for-twitter.html

Answer 4

Cachez des éléments de cache dans une base de données ... Si le cache est trop ancien, demandez les dernières données via l'API.

Pensez également à mettre votre compte d'application sur la liste blanche, cela vous permettra d'avoir une limite de 20 000 api de demandes par heure par rapport au maigre 100 (qui est destiné à un utilisateur et non à une application).

http://twitter.com/help/request_whitelisting