Que s’est-il passé aux APIdays 2014 à Paris ?

 Les APIDays, c’est une conférence internationale donnée chaque année dans plusieurs villes, comme Barcelone, Berlin ou encore San Francisco. Ces 2 et 3 décembre, elle était donnée à Paris, pour la 3ème année consécutive en France, et accueillait près de 700 participants et 60 intervenants dont plusieurs venus tout droit d’Angleterre, d’Espagne ou des États-Unis.

Il est question, bien sûr, d’API mais il s’agit ici d’API WEB : Application Programming Interface WEB. Auparavant, les API étaient utilisées uniquement pour communiquer entre une bibliothèque de composants et le programme principal. A l’heure d’Internet, des services WEB sont mis à disposition contre rémunération, ou non, pour remplir les tâches les plus simples, par exemple pour connaitre l’heure, ou les plus complexes, comme le calcul d’itinéraire, l’obtention d’un flux musical…

Parmi les sujets abordés, on a parlé de l’importance de la qualité des API, d’architecture technique avec Docker, de styles d’architecture avec REST, de l’importance des sketches dans le design, on a fait un rapide tour des API Twitter et on a conclu sur les API hypermédia.

Voilà quelques extraits de ce qui a été vus et entendus aux APIdays 2014.

Mise à disposition

La mise à disposition publique d’une API nécessite la réalisation de tests afin d’assurer la qualité de l’API.

L’API en elle-même est uniquement la partie visible de l’iceberg. En effet, la tester signifie finalement tester le code qui est mise en œuvre lors de son invocation.

• Tests fonctionnels
• Tests de charge
• Tests de sécurité

L’objectif que veut nous rappeler Lorinda Brandion, de Smartbear, dans son exposé « API Readness : is your API ready for primetime? », est une évidence. Les API sont la vitrine de celui qui les produit, donc leur qualité aura un impact sur l’image de leur fournisseur.

A garder en mémoire : Si une API est mise à disposition avec des anomalies, alors les utilisateurs ne vont pas mettre longtemps pour les trouver et, sans solution, abandonner son usage.

Configuration applicative et gestion des droits d’accès

Une application a toujours besoin de s’authentifier pour accéder à des services. Par exemple, pour accéder à une base de données, la configuration applicative varie selon l’environnement.

Voilà différentes solutions, de la moins recommandable à la plus souple, afin d’éviter de modifier l’application à chaque changement de configuration :

• Ne pas conserver les clés de sécurité (credential) dans le gestionnaire de sources de l’application
• La configuration peut être stockée en base de données
• On peut utiliser un service spécialisé comme zookeeper (bibliothèque et serveur local pour la gestion des configurations)
• On peut utiliser un DNS dynamique
• Ou utiliser Docker avec le pattern AMBASSADORS : l’application FRONT pointe alors toujours sur le proxy de la base de données, tandis que la base de données répond toujours au proxy de l’application. Et ce sont seulement les configurations de ces proxys qui changent en fonction du contexte.

Dans le schéma ci-dessous, on a 2 containers Docker (un web container et un database container), chacun relié à leur AMBASSADOR.

[Jérôme Petazzoni, senior evangelist, Docker] Shipping applications to production in containers with Docker

A retenir : Grâce à un couplage faible entre le composant web et le composant Base de données, une application bénéficie d’une très grande souplesse de paramétrage.

WEB API, REST API, quelle forme devraient adopter nos API ?

Les API devraient respecter le principe architectural REST, qui implique en particulier qu’une API doit être sans état (point 2).

Afin d’améliorer la qualité des API, plusieurs modèles de maturité sont proposés :

• Richardson Maturity Model
  1. Le Niveau 1 du modèle propose une réponse au problème de la complexité des programmes : plusieurs petites API sont plus faciles à maintenir qu’un gros programme.
  2. Le Niveau 2 propose une syntaxe et des mots clés (verbs) : GET, POST, PUT, DELETE, UPDATE, … Quel que soit l’API, l’opération DELETE aura toujours pour conséquence de supprimer une entité.
  3. Le Niveau 3 propose l’auto-découverte : l’API est alors auto-documentée et on peut l’interroger pour savoir comment l’utiliser (introspection). On parle d’hypermédia.
• Rob Zazueta (Director of platform, Intel) propose un autre modèle de maturité : NARWL
  1. Le niveau 0 propose de définir des noms standardisés qui sont les entités du métier. Exemple : si l’url /products/:id renvoie un produit, elle peut renvoyer aussi des informations du fabriquant. Si celles-ci sont nombreuses, alors on devrait définir une sous-entité « manufacturer ». Dès lors, on accède aux informations du fabricant avec cette url : /products/:id/manufacturer
  2. Le niveau 1 devrait proposer une réponse au format JSON « rigoureux »
  3. Au niveau 2, le type mine devrait être spécifique au contenu renvoyé (note : le contenu mine devrait toujours être spécifié même si c’est pour indiquer un type générique au niveau 0 ou 1)
  4. Le niveau 3 propose d’auto-documenter l’ensemble de l’API tout comme le Modèle de Maturité de Richardson.

Hiérarchie des besoins pour une API

Bruno Pedro – API Hierarchy of Needs

Inspirée de la pyramide de Maslow : cette hiérarchie permet de décrire le niveau d’utilisation d’une API.

• Usability : l’API doit être testable : on peut la mettre en œuvre. Elle devrait répondre à la règle de 3:30:3 par Ori Pekelman : 3 secondes pour comprendre ce que fait l’API, 30 secondes pour trouver le point d’entrée et 3 minutes pour commencer à l’utiliser et consommer des données.
• Functionality : l’API est conforme à ses spécifications
• Reliability : l’API répond de manière conforme et attendue dans le temps
• Proficiency : l’utilisation de l’API permet de faire gagner du temps en évitant le développement des fonctionnalités qu’elle propose
• Creativity : l’API est utilisable en un sens qui n’avait pas été prévu initialement mais répond de manière cohérente.

Plus une API définira un haut niveau de besoin et plus elle apportera de satisfaction à ses utilisateurs. Si le niveau Functionality est suffisant pour un prototype, il faut au moins atteindre le niveau Reliability pour une utilisation en production.

L’effort pour passer au niveau supérieur est de plus en plus important et peu d’API atteignent le niveau Creativity. Il faudra donc accorder l’investissement, l’effort à fournir et la cible recherchée.

Quelle est un bon design pour une API ?

Ronnie Mitra,  Directeur de API Design chez CA Technologies explique qu’une API doit répondre aux critères suivants : Être solide (homogène et unitaire), utile, utilisable, mais aussi désirable.  Pour atteindre ces objectifs, il met en avant la nécessité de réaliser des croquis (sketch), c’est-à-dire d’itérer pendant les phases de conception et non pendant les phases de réalisation :

1. Créer le projet
2. Définir le vocabulaire
3. Faire des croquis

Ci-dessus F.Guerry et B. Arnault devant la fondation LVMH : En tant qu’architecte, l’utilisation de croquis est indispensable pendant la phase de conception.

Bill Buxton, dans son livre « Sketching User Experiences », remet en avant une idée bien ancienne qu’on retrouve exprimée sous la forme « fail early and fail often ». La conception de tout système ou œuvre passe par de multiples essais et erreurs. Plus le design a une place importante dans le produit fini, plus il est nécessaire d’investir dans la conception, donc investir dans les sketches avant d’investir dans le prototype. C’est ce qu’illustre le schéma ci-dessous :

 

A retenir : Les API définissent une interface : le point de communication entre un fournisseur et un consommateur d’informations. L’API doit rester stable au fil de ses évolutions et son ergonomie doit être adaptée à l’utilisation.

C’est la qualité de la phase de conception qui permettra d’assurer le succès d’une API. Et c’est seulement en passant par de nombreux essais et erreurs, en affinant un peu plus le design à chaque itération, qu’on obtiendra finalement une API de qualité.

Pour aller plus loin : les slides sur l’art de la conception d’API de Ronnie Mitra,

 

Fabric & API : comment bénéficier des outils Twitter

Documentation Twitter

Twitter met à disposition un ensemble d’API et d’outils pour développer des applications Mobiles ou des sites web. Les fonctionnalités sont les suivantes :

• Accès à l’ensemble des fonctionnalités de Twitter grâce à son API REST.
• Améliorer l’accès : login avec le compte Tweeter ou avec le numéro de téléphone (Digits).
• Améliorer la stabilité : Fabric propose une vue synthétique des anomalies en cours, ainsi que l’importance des anomalies en regard de leurs fréquences d’apparition.
• Améliorer la distribution : proposer des API utilisables sans login ou avec un login « Guest »
• Monétiser l’application grâce à l’API Ads et MoPub.
• Mettre en place des statistiques d’utilisation : Cannonball équivalent à Analytics mais pour des applications mobiles.

Au final : on voit que Twitter met les moyens pour se positionner en tant que fournisseur d’API. C’est le cas d’ailleurs pour tous les grands groupes de l’IT : chez Google, chez Microsoft ou chez Facebook.

Bref c’est une bonne nouvelle pour le développement de site web et surtout pour nos applications mobiles.

Au-delà de REST et les API Hypermédia

Ori Pekelman introduit l’idée que le protocole http et le style d’architecture qu’est REST ne sont parfois pas suffisants pour exprimer les API.

Il propose en retour d’implémenter des API en utilisant le gestionnaire de version GIT. En particulier il voudrait tirer parti de GIT pour implémenter des API décentralisées et sémantiques.

Les API Hypermédia

Les API Hypermedia ne sont pas normalisées : elles décrivent elles-mêmes la façon dont il faut les invoquer. Par exemple, si une Api donne l’heure, un premier appel permettra de connaitre la méthode à appeler pour obtenir l’heure, puis le deuxième appel invoquera la méthode retournée par le premier appel.

Cette construction permet de s’affranchir complètement de l’interface de l’API puisque, celle-ci étant auto-documentée, elle donne son propre mode d’emploi.

L’API est auto-évolutive et continuera à fonctionner même si le service appelé évolue.

Vous trouverez ici un exemple d’API hypermédia.

Alors faut-il utiliser des API hypermédia ? Oui, si vous voulez rendre votre application évolutive et réduire les coûts de maintenance. La contrepartie est peut-être une plus grande difficulté de débogage car on va être amené à déboguer du code qui est potentiellement retourné par l’API. Donc non, si vous voulez maîtriser finement le comportement ou le temps de réponse des API invoquées.

En conclusion

APIdays n’a duré que deux jours mais elle fut très riche. Riche de nombreuses conférences sur des sujets aussi bien d’architecture technique que sur des sujets d’évangélisation autour des API.

Je terminerai en faisant un retour sur la conférence de Mike Amundsen. Lors de sa keynote du mardi matin, il cite Alan Kay : “The best way to predict the future is to invent it.”

Alan Kay’s 1972 Dynabook