Cette journée aux APIDays Barcelona a été d'une rare richesse ! Pour commencer, bravo à toute l'équipe et tous les participants !
Je vais tenter de faire un retour le plus complet possible, en restant un minimum concis :) S'il y a des points obscurs, «lache tes coms» [1] !
L'évènement
APIdays est un évènement qui a lieu dans plusieurs villes, et par chance aussi à Barcelone.
Naïvement, je n'aurais jamais pensé qu'il puisse exister une communauté aussi forte autour des APIs ! Je découvre donc une nouvelle famille de passionnés, pluri-disciplinaire et agnostique \o/. Des nouveaux métiers et des participants de tous horizons, de la grosse multinationale aux obédiences XML/Java à la startup hype en passant par des indépendants de toute sorte !
L'affordance
L'affordance, formulé par Don Norman, est un concept assez connu en ergonomie. Cela définit la capacité d'un objet à transmettre ses fonctionnalités via son apparence. Pensez aux poignées de porte, selon leur forme on sait si on doit tourner, tirer ou pousser.
Mike Amundsen ouvrait la journée en étendant le concept aux APIs. Une API, et l'apparence des informations présentées, doit suggérer ce qu'on peut faire avec.
Il a rappelé cependant que les meilleurs designs étaient ceux qui permettaient de faire des choses choses auxquelles les auteurs n'avaient pas pensé.
A good API is hard to misuse.
—Orlando Kalossakas, plus tard dans la journée.
Hypermedia
Plusieurs fois dans la journée, les évangélistes et fins prédicateurs ont expliqué que le monde des APIs était là où était le Web il y 15 ans. On a dépassé le stade d'utiliser GET /action=create et REST est bien implanté, mais l'accessibilité des APIs, leur fédération, leur utilisation transparente ou leur caractère inter-changeable semble encore loin.
Les APIs manquent de liens.
Hypermedia is just like hypertext but not limited to...text!
—Ross Garett
Le Web était initialement pensé comme une gigantesque base de données distribuée et exploitable sans préconfiguration. Sur le tard, il y a eu diverses initiatives, comme le Web sémantique, avec les graphes d'ontologie, RDF ou les micro-formats. On devrait pouvoir dire aujourd'hui que c'est un échec, car cela n'a pas été adopté partout.
Mais, mais... il y a encore de l'espoir avec les APIs :) [2]
Conventions
En contrebas du Web ou des APIs sémantiques, il y a l'approche qui consiste à mettre au point des conventions simples.
Steve Klabnik qui a une culture Ruby a fait le parallèle avec les frameworks Web et l'approche «Convention over configuration».
C'est le cas de la spécification JSON-API, qui ne cherche pas à aborder les concepts de sémantique mais simplement d'économiser aux développeurs de débattre des choix inutiles.
I looked in Google Images to find pictures of bikesheds and found that. I thought «that's not a bikeshed». OMG, I was actually bikeshedding about bikesheds!
—Steve
Par la même occasion, l'idée est de faciliter l'implémentation des clients, et le composant data Ember.js supportera la spec dans la prochaine release.
Nos intentions pour Cliquet sont exactement celles-ci. Nous allons donc probablement converger. D'autant que les specs sont très proches.
Documentation d'API
J'ai pu assister à une excellente présentation de Yann Irbah, qui résumait les bonnes pratiques pour documenter une API sous forme de produit.
Les points importants:
- Exposer la valeur ajoutée du produit : Pourquoi est-ce qu'il simplifie la vie ?
- Documenter les premiers pas jusqu'à l'utilisation avancée ;
- Ne pas se contenter du «hello world» ;
- Écrire des tutoriaux pour chacun des cas d'utilisation ;
- Les développeurs constituent un excellent vecteur marketting ;
- Aider Ă avoir confiance en l'outil ;
- Proposer une documentation avec des end-points interactifs ;
- Mettre Ă jour en continu.
Swagger et Slate ont le vent en poupe.
Il est possible d'aller très très loin, avec des outils qui mettent à jour les snippets de la doc quand l'API change par exemple...
Annuaire d'API
La dernière conférence de la journée était celle de Kin Lane sur les cycles de vie des APIs.
Il a présenté http://apis.io, un annuaire d'APIs.
L'idée consiste à écrire un fichier apis.json, un peu l'équivalent des sitemaps, mais pour les APIs.
Celui-ci va décrire les end-points (en référençant un fichier Swagger par exemple) et ajouter des métadonnées (description, tags, version, blog URI, licence, ...).
Cela n'a pas seulement pour objectif de construire un annuaire global ! Cela peut ĂŞtre un annuaire local Ă l'infrastructure que les (micro)services interrogent, plutĂ´t que reposer sur une configuration en dur (a.k.a Service discovery).
À terme, on pourrait aussi imaginer que tous les appareils de la maison qui disposent d'une API viennent s'enregistrer sur le routeur ADSL du domicile ! Ainsi en un seul coup d'oeil on pourrait avoir accès à leur documentation et les bidouiller ! Voire même que les appareils se détectent et se connectent entre eux automatiquement si leurs APIs respectives suivent des normes/standards.
Discussions
Cette journée a été l'occasion de faire des rencontres ! Tout d'abord, ce fût un grand plaisir de retrouver Silvia, qui a été la première à contribuer sur Cliquet !
« Loosely coupled »
De nombreux participants semblaient nous rejoindre sur l'idée qu'une solution à un problème ne doit pas être pas liée à une implémentation (ex. CouchDB).
Il semblerait que les grandes idées passent aujourd'hui d'abord par la définition d'un protocole, puis seulement ensuite par la proposition d'implémentations de référence (e.g. http://matrix.org, http://wamp.ws/).
C'est une condition nécessaire pour que les services soient «faiblement liés», simples et interchangeables.
Kinto est pertinent
En échangeant, j'ai pu confirmer que ce que nous essayons de faire avec Kinto a du sens. La plupart ont résumé en disant «Oh, un [Parse|Kinvey|Firebase] open-source !». Nous aurons l'occasion d'en reparler, et restons modestes...
Même les gens de Typeform, une startup barcelonaise qui fait une alternative à Google Forms, ont manifesté son intérêt pour ce genre de solution !
L'idée qu'on expérimente autour des permissions et des rôles avec OAuth2 paraissait séduire :) Après un très bref échange avec Medhi fondateur de OAuth.io, il semblerait que les scopes OAuth2 ne suffisent pas pour faire ce qu'on veut.
Mashape Kong
Les gens de Mashape m'ont sauté dessus «Oh Mathieu !». Ça fait drôle ! ... c'était juste grâce à ce tweet sur Kong :]
Ils n'ont pas lâché le mode gros délire, et on a bien papotté, notamment de videur, qu'ils ne connaissaient pas. Ils semblaient bien intéressés par la partie validation de RFC / specs et devraient revenir vers nous :)
Boite Ă outils
Gestion
- http://getkong.org — API middleware
- https://www.apitools.com — API middleware
- https://www.mashape.com — Market place pour APIs
Documentation
- https://docpad.org — générateur de sites statiques ;
- https://apiblueprint.org — comme Swagger mais en markdown ;
- http://raml.org — RESTful API Modeling Language ;
- http://readme.io — Service de documentation
- https://gelato.io — Documentations techniques jolies
- https://apiembed.com — Snippets de requetes API
Studio / Mock / SDK
- https://apiary.io — Studio
- https://www.mocaroni.com — Studio/Mock
- http://mockbin.org — Créer des mock d'API
- http://restunited.com — Génération de SDK
- https://apimatic.io — Génération de SDK
- https://www.getpostman.com — Extension Chrome pour REST
Divers
- API building blocks par Kin Lane
- https://github.com/cjbarber/ToolsOfTheTrade — Services en ligne utiles
- OAuthd — Le daemon de OAuth.io
- http://loader.io — Load testing service
- https://divshot.com — Hébergement de fichiers statiques
- http://schemaform.io — Angular + JSON Schema
- restangular — REST + Angular
- http://sailsjs.org — Framework NodeJS
Conclusion
Les APIs sont partout. Toutes les entreprises ont des APIs. Les APIs sont les blocs avec lesquels les développeurs construiront les applications du futur.
Merci à toutes et tous ceux qui ont participé de près ou de loin à l'organisation de cet évènement fédérateur.
Je vous conseille de guetter les futures dates dans les différentes villes du monde !
| [1] | Bon courage à celui qui tentera de traduire ça tiens ! |
| [2] | http://sookocheff.com/posts/2014-03-11-on-choosing-a-hypermedia-format/ (gist: https://gist.github.com/soofaloofa/9350847) |