Retour sur les APIDays 2018
La tribu WOAPI (Web Oriented Architecture & APIs) d'OCTO était présente en décembre à la conférence API Days Paris, peut-être LA conférence incontournable sur le sujet. Une conférence dense, de deux jours abordant de nombreux sujets transverses. Une première journée très technique et comme à son habitude, une deuxième journée qui revêt une approche plus sociétale. Elle nous permet de poser la question des développeurs, de l’open source et des API dans la société “en général”.
Nous vous proposons dans cet article de revenir sur les présentations les plus marquantes de ces deux jours avec nos retours et nos avis.
Commençons d'abord par un retour d'expérience global sur la conférence. La suite de l'article sera consacrée à des retours individuels sur les présentations auxquelles nous avons assisté.
Take-away
On retiendra de ces deux jours que dans nos discours comme dans les technologies que l'on implémente, OCTO est plutôt à la pointe des réflexions sur le design, les API Managers, l’architecture, la sécurité, les outils et la philosophie. Mis à part GraphQL, technologie sur laquelle nous avons trop peu de retours d'expérience du fait de la frilosité du marché français, nous n'avons rien à envier aux grands conférenciers qui étaient présents.
Cette année, on remarquera une attention particulière donnée aux questions de gestions d’identités et de sécurité (peut-être un effet lié au déploiement de DSP2 dans les banques ?). On se souviendra de ces café-jus-d’orange pris avec des acteurs des API qu’on ne fréquentait auparavant que par Twitter et de l’incroyable (et effroyable) dernière-conférence sur l’écologie de Jean-Marc Jancovici.
Parce que la magie des API Days s'opère comme cela : entre les éditeurs venant faire la promotion de leur solution, les salles pleines à craquer pour aller voir les talks des derniers API-évangélistes, les discussions business autour de la machine à café, on trouve toujours des conférences pour transformer les sociétés.
Les talks
Digital Identities, how to build an easy to use and secured digital identity solution ?
A voir sur Youtube
How to make sure the «John Smith» who is currently authenticating on your application is really « John Smith» ?
Juliette Delanoe (Ubble) nous présente les étapes essentielles dans la gestion d'identité en ligne. On retient qu’il existe un cadre d'identité numérique défini par l'Union Européenne appelé eIDAS, qui vise à simplifier l'interopérabilité entre les services publics mais également le secteur privé.
Designer les API au quotidien / The design of everyday APIs
Documentation IS NOT a solution for fixing bad design.
Arnaud Lauret (API Handyman), star des API sur twitter, fait un discours sur le design d'API qui reprends peu ou prou la refcard bleue. Il utilise pour cela les fameux mode d’emplois de IKEA. Un talk intéressant qui montre l’alignement du discours de WOAPI, vis à vis de ce qui se fait en matière de design d’API. Des standards qu'il est toujours utile de rappeler.
An API is not enough : crafting a developer experience
Developers are busy. They don’t have time to deal with your salesperson or to talk to someone to know your pricing model.
Adam Kalsey (Cisco) nous invite, dans les discours marketing autour d'une API, à utiliser des termes simples et compréhensibles par tous, et d'éviter le jargon métier, pour simplifier le choix d'une solution. De ce fait, s’aligner sur un vocabulaire commun permet de réduire la complexité pour la compréhension côté business. Si nous rejoignons sa position sur les discours marketing, chez WOAPI nous pensons qu'une fois dans le projet ou lorsque l'on utilise l'API, il faut préférer l'usage des termes métiers précis existants pour s'assurer que développeurs et sponsors clients parlent bien de la même chose. Ces termes métiers, bien définis, fluidifient la communication et rendent le projet plus résilient.
Autre point : donner des exemples dans différents langages et paradigmes est un vrai plus (PHP, Ruby, Java, Promises / Async). C'est très intéressant car cela permet notamment de réduire le TTFAC (Time To First API Call).
Developers are humans too
Donner des notes de versions avec un TL;DR indiquant ce qui a changé, ajouter une page de statut de vos services est aussi une bonne pratique. Les développeurs ne veulent pas se demander s’ils ont cassé quelque chose ou si ce sont les services qui sont en panne après un nouveau déploiement.
Balancing your latency budget : on the future of applications at the edge
A voir sur Slideshare
Yes is quick when yes is maybe
Ori Pekelman nous présente les solutions mises en place chez platform.sh pour optimiser les temps de latence sur leur API. Il propose ici un certains nombre de concepts et d’astuces pour améliorer la latence des connections.
Par exemple, on peut vérifier les token avant d'appeler le serveur d’API et renvoyer directement un NON en cas d’erreur, ou répondre un 202 ACCEPTED de manière provisoire avant une requête demandant un temps d'exécution long.
L'équipe est partagée sur ces recommandations : Thomas n'a pas vu l'utilité car la question de la performance ne s'est jamais posée à de tels niveaux d'optimisation sur ses projets, et que la plupart des projets n'auront pas de tels besoins. Sébastien le rejoint sur ce dernier point mais pense que ces recommandations peuvent être de vrais atouts, dans des cas bien particuliers. Il faut cependant être conscient que cela tord un peu le modèle REST et nécessite plus d'opérations de la part du client et de l'API (mise en place de webhooks, requêtes via sockets, etc.).
Putting the Kit back in SDKs
Darrel Miller (Microsoft) fait le point sur les SDK et leur valeur ajoutée. Pour lui, pour apporter un vrai intérêt, un SDK doit contenir : une configuration de base, un gestionnaire de réponses, un modèle de conteneur de base (pour les collections, les paginations, etc.), un constructeur de requête et des middlewares (auto-auth, redirect, caching, retry handlers, etc.)
Bien qu’on utilise rarement des SDK dans nos projets, et encore moins sous Windows, nous avons trouvé la conférence intéressante, puisque ces SDK regroupent beaucoup de briques que nous devons construire sur nos projets, et en terme d'architecture logicielle.
API security and Identity Intelligence
A voir sur Youtube
Ce talk de Bernard Harguindeguy (Ping Identity) nous explique que la plupart des attaques classiques existent à cause d’un mauvais design d’API et/ou le vol des credentials.
Il répète l'importance de vérifier à chaque requête les droits d’accès aux données et ce même après une connexion réussie, et d'appliquer les règles de sécurité OWASP-WAF.
Ce sont des bonnes pratiques de sécurité, que l'on a tellement l'habitude d'implémenter que l'on oublie parfois que l'on doit les répéter aux gens tous les jours.
Platform : How to Product ?
A voir sur Slideshare
Un talk sur comment faire un bon readme par Jessica Ulyate de HelloFresh. Pour elle, le fichier README doit être comme une recette de cuisine et répondre aux questions suivantes :
- Qu’est ce que je vais faire ? => un TL;DR de ce que fait l'API
- De quels ingrédients ais-je besoin ? => les requirements a installer
- Comment faire ce plat ? => les différentes étapes pour installer et faire son premier appel API
De même, les RELEASE NOTES doivent être comme des brochures, avec des TL;DR, de gros titres et des détails associés à ce derniers.
Enfin, lorsque vous présentez des erreurs à l’utilisateur, vous devriez toujours lui fournir des étapes de résolution si possible ou les causes les plus probables des erreurs, ainsi qu’un lien vers le forum / l’assistance si l’erreur n’est pas évidente.
D'après nous, une conférence qui rappelle les choses simple ; basiques, mais nécessaires. En un mot, faites gagner du temps aux développeurs qui vont utiliser votre API.
Panel : Open API
Avec Kin Lane (API Evangelist), Darrel Miller (Microsoft), Vincenzo Chianese (Stoplight), Mike Ralphson (OpenAPI Initiative), Shelby Switzer (Healthify).
Les langages de description d'API (ADL) ont aidés à créer un écosystème permettant aux développeurs de démarrer un projet d'API facilement avec une étape de design simplifiée et permettant de contrôler le comportement de l'API au cours du développement.
Il ressort cependant que la plupart des personnes utilisant un ADL le génèrent depuis des commentaires dans le code et n'offrent aucune garanties que la documentation ainsi générée reflète réellement le comportement réel du code. Kin Lane propose au lieu de cela, de d'abord concevoir nos API avec des ADL, puis de tester le code par rapport au contrat ainsi décrits.
We don’t need it [API Description Languages]! We already have hypermedia, self-descriptions and /routes endpoints with everything.
Le consensus qui ressort de cette discussion est que les ADL ne sont souvent pas très utiles, si on implémente correctement et jusqu'au bout REST et Hypermedia. Mais comme c'est rarement le cas, ils permettent de combler un manque et servent de béquille en attendant mieux.
Lord of API Design
Arnaud Lauret nous explique l'intérêt de la mutualisation du design d’API au sein d’une même entreprise à travers la réalisation d’un Guide Line comportant les différentes conventions de design établies par l’équipe / designer(s) en amont.
Il explique que pour des centaines d’API publiques, il existe des millions d'API privées au sein des entreprises. Que se passe-t-il si il y a de plus en plus de designs d’API qui arrivent tous les jours ? Que se passerait-il au sein d’une entreprise si une nouvelle API venait à être designée pour couvrir un nouveau use-case ?
Il existe un risque que toutes les API de cette entreprise puissent être différentes d’un point de vue du design, entre elles mais aussi au sein de la même API. En effet, certains endpoints peuvent être pensés différemment, provoquant une incohérence.
Il recommande donc d'avoir un ou plusieurs API designer dans un même plateau. Mais prévient qu'il faut être vigilant lorsque plusieurs personnes sont responsables du design car il peut exister autant de style d’API dans une entreprise qu’il existe de designers.
Pédagogiquement très intéressant, avec une métaphore filée autour d'une œuvre culturelle quasi universelle.
On the sociability of API's
En se servant de l’histoire de l’informatique et des histoires de la vie de tous les jours, Jordi Fernandez d'Adidas, développe une approche craft des API. Il montre que les API, par leur standardisation, servent en partie, d’un côté à réduire les interactions entre humains et à maintenir l’énergie [stamina] des développeurs. L’API aurait un rôle protecteur de par sa capacité d’abstraction.
Pour info, le terme API viendrait de Ira W. Cotton, un ingénieur qui en aurait parlé pour la 1er fois en 1968 dans un article scientifique (p. 353)
MercureHub
Kevin Dunglas (scoop des tilleuls) montre son implémentation de Mercure, un protocole de push très prometteur.
Bien qu’un peu complexe, l’outil promet de faire du temps réel par le serveur en HTTP (sans SDK) le tout avec une API qui gère GraphQL et HATEOAS. A suivre, avec plus d'info sur github : https://github.com/dunglas/mercure.
New API Stack is bullshit
APIM is the new ESB
Un talk un peu frondeur pour mettre un petit coup de pieds dans les API Manager. Rob Z (Tibco) nous explique que les APIM sont les nouveaux ESB.
There is beauty in the chaos infrastructure
Il revient aussi sur les microservices et affirme que, oui c’est un certain bordel, mais qu’il faut assumer cette décentralisation du code, de la documentation et de l’administration. Chez nous on aime les francs-tireurs !
Consumer Driven Contracts
Ankit Sobti, CTO du très bon outil Postman, propose une nouvelle approche de l'API design et testing par le contrat :
- On définit un contrat de ce que doit être l’API
- On l’expose avec des mocks
- Les équipes back ET les équipes front codent l’API dessus en suivant ce contrat
Chez WOAPI nous restons perplexes et nous nous posons des questions sur la compatibilité de cette approche avec la philosophie REST : revenir à un contrat, c'est un peu revenir vers les WSDL de la grande époque SOAP. Un contrat, on le respecte ou on le respecte pas, l’entre deux n’a que peu de place.
REST et plus généralement, l’Open API, sont de bonnes approches pour faire des projets en incrémental.
Exemple : Je lis la spécification, je prends ce petit bout d’API qui m'intéresse, mais pas celui là, ou alors plus tard, cette partie est pas utile, mais le sera pour un autre...
Autre point, il y a un risque de déresponsabiliser les équipes de développeurs, en mettant le pouvoir dans les mains de celui qui écrit le contrat d'API et non pas dans celles de ceux qui vont la développer. A faire attention !
Par ailleurs, on parle ici d’une solution éditeur qui promeut son logiciel. Attention au vendor lock-in !
StopLight.io
A voir sur Youtube
Vincenzo Chianese developpeur de stoplight.io nous en fait une démonstration. C’est une "application magique" (!) : en quelques clics on design une API REST avec une documentation magnifique, des mocks et toutes les tâches d’intégration continue qui vont bien. Cerise sur le gâteau, c’est “OpenAPI 3.0 compliant”.
Attention ! Cette application risque de mettre au chômage mais on a pas encore trouvés de robots-consultants :p
Introduction aux Maintainers : Critique de l'innovation
Andrew Russel, professeur de Sciences Humaines à la Sunny Polytech university et auteur de l’ouvrage “Open Standards and the Digital Age: History, Ideology, and Networks” décrit une société divisée en 3 groupes : les innovateurs, les rentiers et les mainteneurs.
Ses analyses expliquent que la plupart des profits vont aux deux premiers métiers. Les mainteneurs, ceux qui gardent en vie les systèmes inventés et possédés par les 2 premières populations, sont injustement reconnus. L'innovation se fait au dépend de la maintenance et de la soutenabilité des projets.
Cela pose des questions sur la répartition des investissements. Pourquoi préférer l’innovation à la maintenance d’un système ? Est-ce vraiment rentable ? Pourquoi les métiers de la maintenance sont les moins reconnus ?
Andrew Russel nous invite à nous interroger et à nous engager pour une meilleure reconnaissance des mainteneurs. Ce sera un sujet récurrent de la seconde journée de conférence à API Days.
The Digital Transformation people platform
Digital Transformation is the shift of culture where a traditional service company would become a tech company
Une panel avec Kevin Dunglas (les-tilleuls.coop), Vladimir de Turckheim (sqreen.io / NodeJS security team), Shelby Switzer (Healthify) et Tibor Vass (Docker)
Le modèle NodeJS pose un problème: il y a trop de packages qu’on ne regarde jamais. Cela veut dire qu’on exécute le plus souvent du code totalement inconnu sur notre machine.
C’est d’ailleurs la même chose avec tous les gestionnaires de paquets. La responsabilité incombe aux mainteneurs, qui le font souvent pendant leur temps libre, non rémunérés et qui n’ont pas le temps pour faire des revues de code sérieuses. Sur le long terme des bugs ou des failles de sécurité finissent par arriver de manière exponentielle.
Avec des projets grandissants, travailler dans une communauté Open Source devient une activité à temps plein. A un moment, la question de la rémunération des développeurs et des mainteneurs de projet open source se pose.
Il a été question d'une prime pour la résolution de bugs (bug bounty). La communauté paye à chaque fois qu’un bug est résolu ou pour une nouvelle fonctionnalité.
La question du modèle Patreon pour l’ Open-Source a été aussi rappelé : On donne tous les mois de l’argent à un développeur pour qu’il travaille sur un sujet.
Problème : de telles plateformes prélèvent un gros pourcentage, et il est rare que les sommes reçues par les développeurs soient suffisantes pour vivre correctement.
Dans le logiciel propriétaire, c’est l’utilisateur qui paie la solution. Dans l’open source, ce sont souvent les développeurs qui payent (!) mais des modèle existent pour inciter les utilisateurs finaux à donner.
Software is a weird world where everybody expects someone to maintain & take care of open-source projects. This discussion would never happen if we were talking about the construction industry.
L’open source a une contradiction vis-à-vis des mainteneurs: On finit par trouver normal que des gens travaillent gratuitement, et on exige d’eux une certaine qualité dans leur travail.
Dans les faits, on se rend compte que beaucoup de développeurs utilisent leur temps de travail sur ces projets open source en « mentant » ou en « cachant » à leurs employeurs l'utilisation de leur temps.
Ce fut pour nous un très bon panel d’invités avec des discussions profondes. Le modèle économique parfait pour les mainteneurs dans l’Open Source n’a pas encore été trouvé. Mais des pistes ont été avancées. Notamment dans les conférences suivantes.
Open source sustainability, maintainers and licences
Un panel avec Benjamin Jean & Camille Moulin de inno3
La conférence pose la question de comment rémunérer l'open source.
Le problème souligné à de nombreuses reprises est que beaucoup de très grandes entreprise utilisent quotidiennement des logiciels libres sans jamais rémunérer les auteurs. Comment, dans ce cas, maintenir l’aspect “libre” et “open-source” tout en rémunérant les auteurs de Logiciel libre ?
Les conférenciers ont donc proposé un début de travail sur une nouvel licence qui rémunèrerait les droits d'auteurs plus que l’achat de code ou d’executable. De ce fait, les développeurs pourraient garder deux licences sur les projets : une pour le code source comme aujourd'hui dans les projets FLOSS, et une pour la marque associée à ce code (Trademark). Bien que cela n’interdirait pas les forks, en faisant payer l'utilisation de la marque plutôt que sur le code source, on pourrait garantir l’open source et rémunérer les développeurs. Affaire à suivre...
Il y a eu ensuite 2 tables rondes entre “mainteneurs” de l’open source. Par petit groupe de 6 nous nous sommes interrogés sur nos manières de faire vivre l’open source :
- Qu’est ce qui nous pousse à développer ? souvent gratuitement ?
- Quand est-ce qu’on le fait ?
- Est-ce que nos “boss” ont conscience des licences open-sources qu’ils utilisent ?
- Comment ce code est intégré dans nos entreprises ?
Je retiens de ces discussions que peu de développeurs parlent de leur activités libriste à leur employeur, c’est souvent un travail un peu caché, fait à cheval entre les heures de bureaux et le week-end. Ceux qui le font officiellement travaillent souvent dans des espaces un peu marginaux (développeur officiel pour la fondation node.js, universitaire thésard…)
D’autres questions se sont posées sur la possibilité de mettre en place des “caisses d’urgence” pour les développeurs open source qui vivraient des moments compliqués.
Internet and Human Rights
A voir sur Slideshare
Internet became political at the moment when most of human activities started to take place on the internet through software.
Stephane Bortzmyer (AFNIC) nous questionne sur le rapport de la société à Internet, et comment nous, développeurs, pouvons et devons nous poser des questions sur ce que nous développons. La responsabilité éthique des développeurs est selon lui engagée sur chaque projet, et il nous invites à prendre part au « Serment du Beffroi de Montrouge » à ce sujet.
Data is not an asset but a liability
Stéphane invite également les développeurs à toujours challenger les demandes de collectes de données personnelles. En effet, il rappelle à juste titre que la fuite de vos données n'est pas une question de "si" mais de "quand". De ce constat, il martèle le mantra suivant : chaque donnée sur votre serveur est un risque potentiel. Il est donc souhaitable d'en avoir le moins possible pour minimiser les risques.
Nous avons beaucoup aimé cette conférence qui parle d'éthique, de la responsabilité des "doers" et qui essaie de remettre faire prendre conscience aux décideurs que la donnée personnelle n'est pas quelque chose à prendre à la légère.
On y parlera également d'Internet en tant que infrastructure publique permettant le plein exercice des droits humains, et du fait qu’il ne devrait pas être contrôlé.
Our global IT system, energy saver or climate destroyer ?
A voir sur Slideshare
Jean-Marc Jancovici (The Shift Project), avant d'essayer de démontrer si l'industrie IT peut sauver le climat ou au contraire le précipiter vers un dérèglement total, commence par définir ce qu’est l’énergie puis nous montre à quel point nos sociétés ont toujours utilisés de plus en plus d'énergie jusqu'à en devenir “dépendantes”.
L’informatique est un de ces grands consommateur d’énergie (sur l'ensemble du cycle de vie, de l'extraction minière à la production industrialisée, en comptant l'électricité nécessaire pour faire tourner toutes ces machines). En soit, cette industrie ne représente qu'une faible partie des émissions totales de gaz à effet de serre, mais tout de même non négligeable.
Il nous explique cependant, appuyé par de nombreux chiffres clairs et perturbants que le Green IT n'est que poudre aux yeux. En effet, par l'effet de levier que l'informatique provoque dans l'ensemble des autres industries, elle démultiplie la consommation d'énergie de celles-ci en ouvrant des possibilités auparavant impossibles,
C'est une conférence qui nous a fortement marqués, de par les implications sociales et environnementales, appuyées par de nombreuses études et chiffres. L'IT est un démultiplicateur de possibilités et donc par essence, un catalyseur de la production et donc de GES (en l'état actuel de la génération électrique dans le monde). Ce n'est donc pas très optimiste sur le rôle que notre industrie a à jouer dans la lutte contre le dérèglement climatique.
Une conférence similaire de Jean-marc Jancovici est disponible sur Youtube. On vous invite vraiment à la regarder. Ce sera le dernier truc que vous ferez avec un PC avant de nous rejoindre élever des chèvres dans le Larzac !