Alex Payne est le « lead » de l’équipe qui développe l’API de Twitter.

Il est au cœur des enjeux que traverse aujourd’hui Twitter : la croissance incroyable des applications et des sites utilisant Twitter est le résultat direct du travail de son équipe.

La possibilité pour les iraniens de contourner le blocage de Twitter.com en tweetant depuis d’autres sites, c’est aussi grâce à son équipe.

L’API de Twitter est le meilleur des cas possible en terme d’une API Web ouverte : utile, utilisable et réellement utilisée.

Je l’avoue, j’ai donc d’abord eu l’idée d’interviewer Alex pour enrichir la stratégie d’API Web d’un client en stratégie web. Mais impossible de garder ça pour moi :-)

Cette interview inédite apporte un éclairage concret sur la création de l’API de Twitter, son succès et ses ambitions.

« The message bus of the web »

Julien : Quelle est l’utilisation la plus surprenante de l’API, l’usage qui vous a fait dire « Je n’aurais jamais pensé à ça! »

Alex : Le plus surprenant pour moi a été le travail que InSTEDD a fait en utilisant Twitter comme un mécanisme de communication pour le travail humanitaire, à la fois bon marché et étendu.

Je m’attendais à des applications de type clients, de visualisation, de data mining, et ainsi de suite, mais de voir Twitter et notre API utilisés pour du secours a certainement été une agréable surprise.

Julien : Il s’agit d’une utilisation très intéressante : Twitter comme une infrastructure essentielle.

Ce que j’aime ici, c’est la façon dont l’API leur permet de prototyper les processus de communication d’urgence.

Faire des itérations est si rare quand il s’agit de réseaux de communication, c’est de grande valeur ! (parce que nous aimons tous les prototypes et les itérations, cela va sans dire :-)

Mais c’est beaucoup de responsabilité pour Twitter. Et il semble que les gens demandent de plus en plus sur ce point.

Comment voyez-vous cette responsabilité, faisant partie de l’équipe qui a construit l’infrastructure sur laquelle s’appuient autant d’outils?

Alex : C’est une lourde tache à surmonter, mais nous sommes à la hauteur.

Nous savons qu’il y a a tout sorte de chose qui se passe sur Twitter, depuis de la communication d’urgence jusqu’à des transactions commerciales essentielles.

Et nous faisons de notre mieux pour fournir une plate-forme stable, à haute performance, pour ces messages.

Nous avons fait un investissement considérable dans notre infrastructure, d’un point de vue opérationnel, d’un point de vue développement logiciel, et d’un point de vue compétence.

Julien : Comment réagissez-vous face à ce défi en tant que personne ?

Par exemple, que ressentez-vous personnellement par rapport à l’API au sujet du mème #nomaintenance [après l'élection en Iran] ou d’autres signes de Twitter devient de plus en plus perçu comme un service public ?

Alex : Je pense que c’est ce que nous voulons.

Nous voulons que Twitter soit le bus de messagerie du web, « the message bus of the web« , et je pense que nos utilisateurs et les développeurs doivent avoir la plus haute exigence vis-à-vis de notre service.

Nous avons besoin de cette pression pour nous guider.

Julien : Comment pensez-vous que l’on puisse planifier une API pour qu’elle produise des « usages surprenants » ?

Alex: Fournissez simplement autant de données, autant de méthodes et un accès aussi large que possible.

Laissez les développeurs faire tout ce qu’un utilisateur peut faire, et de bons projets émergeront.

Ne traitez pas votre API comme une caractéristique secondaire; lancez systématiquement les nouvelles fonctionnalités avec des méthodes correspondantes dans l’API.

L’erreur à ne pas commettre…

Julien : Quelles sont les erreurs que vous ne referez pas, mais que vous voyez les autres faire encore et encore ! Je pose cette question en pensant à cette présentation plus ancienne.

Alex : Versionner, versionner, versionner. Je ne concevrais jamais plus une API web sans gérer les versions depuis le premier jour !

De nos jours, je pense aussi qu’il est fou de ne pas fournir OAuth dès le départ si vous partez de zéro.

Nous n’avions pas cette possibilité [OAuth n'étant pas finalisé] quand nous avons commençé à fournir notre API, mais je pense qu’un type ou un autre d’authentification basé sur un échange de jeton [token] est la chemin à prendre.

Julien : Je peux imaginer que ne pas avoir de gestion des versions peut mener à des situations inconfortables pour les développeurs, parce que vous changez des choses, et que cela casse le fonctionnement de leurs applications.

Comment cela est-il devenu de plus en plus bloquant ? Est-ce que cela vous restreint, en tant qu’équipe gérant l’API ?

Alex : Cela est devenu bloquant au fur et à mesure que les applications Twitter ont migrées du web, où les mises à jours et les modifications rapides sont faciles, vers les téléphones et même le matériel embarqué, qui dans certains cas ne peuvent être mis à jour uniquement qu’en re-flashant.

L’absence de de gestion des versions nous sans aucun doute empéchée de faire des changements plus drastiques.

Julien : Mais pourquoi n’était-il pas possible de simplement d’ajouter /1.1/ dans l’URL, de retomber sur une version gelée si la version n’était pas précisée – et de démarrer la gestion des versions de cette manière ?

Alex : Nous voulons que les auteurs de clients soient explicites dans leur code à propos de la version qu’ils utilisent.

A propos de OAuth

Julien : En tant qu’utilisateur, j’adore OAuth. C‚Äôest une bien meilleure solution que de donner son login et son mot de passe à un tiers !

Mais le processus d’authentification très basique a fait parti du succès de l’API de Twitter, en abaissant fortement la barrière d’implémentation quand il s’agissait de construire des applications ou des flux de données authentifiés.

Avec le recul, vous aviez raison de démarrer sur la simplicité pure, puis d’ajouter plus de sécurité en second.

Comment trouve-t-on cet équilibre ?

Alex : Je pense que Basic Auth [l'authentification historique de Twitter] est certainement plus simple pour les développeurs (et, dans certains cas, pour les utilisateurs) pour démarrer.

Nous allons essayer de conserver cette faible barrière à l’entrée en fournissant un proxy de Basic Auth vers OAuth pour les usages de développement local, et en fournissant un moyen d’explorer les méthodes de l’API Twitter via le web (une console de test).

[Note : un bon exemple de console de ce type est la console de test de SoundCloud]

La communauté des développeurs

Julien : A-t-il été facile au départ de recueillir les retours des utilisateurs de l’API, alias les développeurs ?

Alex : Oui, complètement. Nous avions une communauté bien plus petite quand j’ai commencé à passer du temps sur notre API, mais ils s’exprimaient et étaient actifs. Les fondations de notre API ont grandies en réponse à leurs besoins et à leurs préférences.

Julien : Quelle a été le retour, la demande la plus surprenante ?

Alex : A mesure que nous grandissions, j’ai été surpris d’à quel point notre communauté de développeurs a grandi avec nous.

Il y a deux ans, nous n’aurions jamais eu besoin de méthodes de l’API qui renvoient d’énormes listes dénormalisées d’ID utilisateurs, par exemple.

Les développeurs pouvaient se débrouiller avec un peu de pagination. Il a été surprenant et gratifiant de voir que nos développeurs « montent en échelle » avec nous.

Gérer et faire converger deux APIs

Julien : Le problème de la fusion de deux APIs est quelque chose auquel vous devez faire face, avec l’API de recherche…

Vous contentez-vous de faire des itérations pour atteindre une certaine cohérence? Ou pensez-vous qu’il y a une bonne façon d’intégrer l’API de recherche – et même de converger avec des APIs extérieures-mais-amies comme bit.ly ?

Alex : Je pense qu’en fournissant des APIs cohérentes et bien documentées, nous pouvons satisfaire tout le monde. Plus nos conventions sont fortes, plus il est facile de se familiariser avec notre API.

C’est notre objectif et nous faisons participer notre communauté de développeurs autant que possible pour être s√ªr que nous fournissons ce que les gens veulent.

Nous sommes assez clairs sur ce que nous devons faire pour l’API de recherche. C’est une API très puissante, mais heureusement elle est aussi très simple à utiliser.

L’intégration, dans ce cas, consiste en grande partie à s’assurer que les données que vous obtenez sont les même quelle que soit l’API que vous utilisez.

En termes d’intégration avec les API externes, il s’agit surtout de diriger les gens dans la bonne direction. Nous faisons en général très peu de facilitation sur ce point; les auteurs des clients trouvent d’autres APIs qui fonctionnent bien avec nos APIs, et l’info circule.

Nous aimons REST

Julien : Y a-t-il eu des moments où vous avez ressenti que le paradigme REST était une limitation — par rapport à des choix plus complexes ou complets comme SOAP ?

Alex : Non, pas vraiment.

Nous avons eu des demandes occasionnelles de fournir du SOAP ou un autre transport lourds, mais la plupart des développeurs semblent heureux de travailler avec une API RESTful.

Ce serait même plutôt le contraire, notre API va devenir encore plus RESTful à mesure de son évolution. Nous n’exploitons pas tous les avantages que le modèle REST a à offrir, pour le moment.

Julien : Les critiques disent fréquemment que beaucoup d’APIs web ne sont pas du tout du vrai REST. C’est un débat similaire au débat ou à la confusion autour des web app MVC.

Avez-vous ce sentiment que l’API twitter n’est pas vraiment RESTful, mais que votre objectif est de tendre vers une vrai implémentattion RESTful ?

Alex : Je pense que certaines méthodes dans l’API Twitter sont plus proches de la définition académique de REST (dans lequel les ressources sont exposées comme des noms pluriels qui sont modifiés par des verbes sous forme de méthodes HTTP).

Mais beaucoup des méthodes plus récentes ne le sont pas.

Notre objectif est de normaliser les noms de nos méthodes selon les conventions RESTful.

Julien Dorra est coach en stratégie web.

Tags : Alex Payne, Iran, Julien Dorra, Twitter Inc

Recommandez cet article à vos amis

et rejoignez nous sur Facebook et Twitter...