rémian dovène

J’ai souvent pensé que fournir une API aux développeurs pouvait comporter des risques de stabilité pour le service web qui la propose. Le cas typique d’une application tierce mal conçue peu devenir vite un trouble pour l’application web principale. Il semblerai que ce soit le cas de Twitter actuellement.

Nous apprenons sur l’un des billets du blog de Twitter la raison des récentes arrêt de service.

Nous avons trouvé une utilisation de l’API qui consomme trop de nos ressources dédiées à Jabber. Cette activité avait pour effet de surcharger notre base de données, ayant pour conséquence les pages d’erreurs et les lenteurs que la plupart des utilisateurs ont rencontré. [..] Nous allons observer les clients de messagerie instantané avec grande attention.

Twitter est l’un de ces projets qui ont prit le parti d’externaliser le développement de ses applications par d’autres personnes. C’est la tendance actuelle des services web sociaux lié à la publication. Je pense qu’en effet c’est la bonne méthode lorsqu’on décide de lancer un nouveau service. Cependant si l’application comporte des erreurs de conception, et si l’API n’est pas capable de bien gérer ces anomalies, arrive alors les pannes de serveur, surcharge, indisponibilité.

Ces incohérences se détectent progressivement, c’est la vie d’un service de le faire évoluer me direz-vous. Mais si ces incohérences prennent un certain temps pour les détecter, et que pendant ce temps là, les utilisateurs en sont frustrés, alors en découle mécontentement et donne au service une mauvaise image.

A l’évidence, c’est une donnée à prendre en compte si vous souhaitez un jour monter une startup en bootstrapping avec comme projet principal, un service web et son API, en laissant à d’autres le soin de développer pour vous les applications.