La conception et la description d'API sont bien plus qu'un contrat d'interface technique entre machines. Jakub Nesetril le co-fondateur et CEO d'Apiary souligne que le vrai consommateur d'une description d'API c'est un développeur, avec toutes les préoccupations d'engagement, de convivialité et de communication que cela implique. Nous avons échangé récemment avec Jakub sur l'approche d'Apiary pour concevoir une API et sur les outils d'APIs et les workflows émergents.
InfoQ : Jakub, vous avez récemment animé à la conférence API Strategy une présentation sur les meilleures pratiques de conception d'API. Vous y avez précisé qu'il n'y a pas "une seule manière de construire une API". Pouvez-vous nous parler un peu plus de cette philosophie et comment cela se rapporte à ce que vous faites chez Apiary?
JN : Historiquement l'API a été considéré comme l'interface entre deux programmes informatiques. En réalité, l'API est une interface entre les développeurs - de vraies personnes. Si les développeurs ne savent pas comment utiliser votre API, alors c'est terminé, votre projet va échouer.
L'API (et la conception d'interface logicielle en générale) se comporte de manière très similaire à la conception des interfaces graphiques : elle est influencée par les cycle de la mode, elle est différente en fonction du milieu culturel (en programmation cela signifie généralement la culture au niveau des langages et des frameworks), il est facile d'avoir des avis très tranchés mais personne ne s'accorde sur ce qu'est la bonne conception.
Tout comme il serait stupide de chercher la "seule et unique" conception d'interface graphique, il n'y a pas une conception d'API canonique. Il existe par contre des techniques pour atténuer la subjectivité inhérente de cette conception. Comme nous l'avons vu avec l'évolution de l'interface utilisateur, dans la dernière décennie, une attention particulière sur la conception centrée sur l'utilisateur et l'émergence de l'expérience utilisateur au centre de la conception. Nous devons apporter la même approche au développement d'API, centrée autour de l'agilité, des itérations rapides, et des retours d'informations forts avec les clients et les parties prenantes.
InfoQ : Il y a de nombreux standards de description d'API en compétition, y compris le votre API Blueprint. Certains d'entre eux sont basés sur JSON, Markdown ou YAML ou même XML. Avez-vous une vision sur l'approche qui serait la meilleure? Qu'est-ce qui vous a fait choisir Markdown plutôt que les autres solutions?
JN : Les formats XML, JSON et YAML existaient déjà lorsque nous avons démarré Apiary, et nous nous sommes efforcé de ne pas inventer quelque chose de nouveau. Nous étions convaincus que ces langages étaient beaucoup trop complexes, surtout si vous invitez d'autres types de profils — un rédacteur de documentation technique ou votre consommateur d'API — à participer. Ils ont aussi tendance à être vraiment gênants pour prendre en charge une grande quantité de texte lisible par l'homme, quelque chose qu'une bonne documentation d'API tend à avoir.
Nous cherchions un format qui soit populaire parmi les développeurs, qui puisse être utilisé pour écrire des données structurées mais également des paragraphes de prose. Notre objectif était de trouver quelque chose de très lisible par l'homme et facile d'écrire par l'homme. Nous voulions qu'il soit compréhensible à la fois par des personnes techniques et non techniques. Pendant des années markdown a été utilisé par pratiquement tous les projets open source et il est le coeur des pages GitHub et des systèmes de publication Jekyll. Les développeurs l'utilisaient depuis des années.
InfoQ : Certains développeurs recommandent hypermedia comme une alternative au développement d'API basée sur un contrat. La réponse peut paraître évidente mais que pensez-vous des APIs contrats vis à vis des non contrats?
JN : Nous voyons un grand potentiel pour Hymermedia, mais il a toujours pour l'instant une attraction limitée. Hypermedia a du mal à être adopté. Si il était adopté largement nous pourrions voir des changements spectaculaires du côté de la consommation d'APIs, cependant l'utilité des contrats est toujours là, notamment pour la validation, les tests automatisés et l'outillage qu'ils apportent. Sans un meilleur support des outils, la situation est susceptible de rester ainsi. Cependant beaucoup de personnes intelligentes essayent d'améliorer l'outillage, nous allons donc voir comment cela va évoluer à l'avenir.
InfoQ : Vous avez lancé récemment l'outil Dredd pour les tests automatisés d'implémentation d'API vis à vis d'un plan. Vous semblez travailler sur un workflow spécifique pour la conception et le développement d'API. Pouvez-vous nous détailler ce point?
JN : Le développement logiciel a évolué au cours de cette dernière décennie vers une préférence pour les itérations agiles plutôt que la conception traditionnelle, statique et en cascade. Avec l'agilité nous avons vu des choses comme les tests automatisés, la couverture du code et l'intégration continue émergente. Mais quand il s'agit d'APIs et de contrats d'interface, nous sommes toujours comme en 1999 - une conception initiale, des projets de développement monumentaux, de la documentation obsolète, aucune couverture de code, pas d'intégration continue. Chez Apiary nous travaillons pour changer cela.
Dredd est un bon exemple pour cela. Tous les développeurs savent que les tâches manuelles, sources d'erreurs, doivent être automatisées. S'assurer que votre documentation d'API reste d'actualité est justement l'une d'entre elles. Tout le monde déteste maintenir de la documentation. Avec Dreed nous apportons la couverture de code à votre documentation d'API, d'une manière qui est fondamentalement compatible avec n'importe quel fournisseur d'intégration continue.
InfoQ : L'engagement du développeur semble être "l'ingrédient secret" pour l'adoption et le succès d'une API. Quels sont les principaux points que tout le monde oublie en terme d'engagement du développeur?
JN : L'accent sur la convivialité et l'autonomisation - est encore rare. Si vous regardez TOUS les projets d'API qui sont un succès (et les sociétés centrées sur les développeurs en générale), Ils ont tous une marque forte, une magnifique expérience utilisateur dans leurs produits et ils permettent à leurs utilisateurs de faire des choses qu'is ne pensaient pas être possibles avant. Ce n'est pas sorcier, mais c'est plus dur à recréer. L'empathie pour les besoins des utilisateurs n'est pas une sensation facile à éduquer et à acquérir. C'est pourquoi beaucoup de conception d'Apiary sont concentrées sur la réunion des personnes : les concepteurs d'APIs, les développeurs d'APIs, les consommateurs d'APIs - pour créer un environnement où il est facile pour eux de communiquer.
InfoQ : Vous avez 25 000 APIs en cours de développement avec Apiary, avez-vous des plans pour tirer partie de cette position, comme une place de marché d'API ou un référentiel?
JN : Ce nombre augmente chaque semaine, il est donc difficile d'en garder une trace. Nous sommes à 35k et nous grimpons. Il y a à peine un an, les analystes de l'industrie discutaient sérieusement si il y avait 50 000 ou 80 000 APIs au total dans le monde. Maintenant nous savons que le nombre réel est beaucoup, beaucoup plus grand. Malgré une croissance importante d'Apiary en seulement 12 mois, la majorité de l'industrie utilise pour ses besoins internes, des outils faits sur mesure. Il y a beaucoup d'espace pour se développer.
Nous nous concentrons sur ce que nous faisons de mieux - construire des outils qui responsabilisent les développeurs. L'idée d'une place de marché pour les APIs ou un référentiel semble attirante d'un premier abord, mais nous n'avons jusque là rien vu qui puisse vraiment apporter de la valeur.
Apiary Inc. est basée à San Francisco avec de l'ingenierie opérationnelle à Prague en république tchèque. Elle a été fondée par Jakub Nesetril et Jan Moravec et a ouvert, à la fin de l'année 2012, une beta publique de sa plate-forme innovante de conception d'API. A ce jour Apiary a rassemblé plus de 35 000 APIs, ce qui en fait la collection d'APIs la plus importante au monde. Parmi ses premiers clients on compte des développeurs des portails Akamai ou GoodData. Nous avons récemment échangé avec Jakub Nesetril sur la conception, la description d'API, sur l'outillage et les tests.