pourquoi est-ce si difficile de concevoir une api ?
TRANSCRIPT
HumanTalks ParisPourquoi est-ce si difficile de concevoir une API ?12 Janvier 2016 @Deezer
Alexandre ESTELA@alx_estela
22
A propos du talk
API : API RESTful basée sur HTTP
Concevoir une API : Définir l’interface d’échange avec le consommateur
33
A propos du speaker
Consultant Senior chez Palo IT
Evangélisateur et Architecte SOA & API
Souvent surpris par les (mauvaises) pratiques de conception autour des API
44
A propos des API mal conçues
L’API nostalgique de SOAP L’API miroir du Système d’Information
L’API à rétro-engineerer soi-mêmeL’API taillée pour 1 consommateur
5
API mal conçues :Est-ce un problème de technologie ?
66
La technologie n’est pas un problème
La stack technologique est standardisée et largement éprouvée
Transport HTTPEnveloppes quasi-exclusivement au format JSON
Les techniques de sécurisation sont à peu près standardisées
HTTPS / TLSHTTP Basic AuthOAuth 2.0OpenID Connect
Il n’y a pas a priori d’évolution prévue ayant un impact significatif
HTTP 2
7
API mal conçues :Est-ce un problème
de concept ?
88
L’appropriation des concepts est un point d’attention
REST n’est hélas pas un standard « out of the box »
Il faut comprendre les concepts théoriquesURI, Ressources et ReprésentationsMéthodes protocolaires explicites (e.g. GET, PUT, …)Hypertext / Hypermedia / HATEOASTransfert d’état
Il faut choisir les (bonnes) pratiques adaptées au contexte
Granularité des ressourcesHeaders HTTPGestion de sessionVersioning
9
API mal conçues :Est-ce un problème
d’outillage ?
1010
Le choix de l’outillage est un point d’attention
3 formats principaux de spécificationSwagger 2.0RAML 1.0Blueprint
Chaque format a ses forces et faiblessesCapacités de spécification d’APIParseurs et éditeursGénérateurs de code et de documentationIntégration avec d’autres langages et technologies
L’écosystème des formats tend à s’harmoniserConvergence des capacités des 3 formatsOpen API Initiative
11
API mal conçues :Est-ce un problème
de méthodologie ?
1212
Le choix de la méthodologie est critique
Plusieurs approches méthodologiques sont possibles« Top-Down », « Bottom-Up », « Test-Driven » …
Il importe d’identifier les facteurs de succès pour le contexte
Priorisation des fonctionnalités à plus forte valeur ajoutéeFédération ou formation d’une communauté de développeurs (« DX »)Anticipation des contraintes amenées par les SI / organisation / partenaires
Dans tous les cas, il faut recourir au prototypage, puis itérer
Plateformes ciblesJeux de données concretsVrais consommateurs (dont « early adopters »)Vrais cas de test
13
API mal conçues :Est-ce un problème de collaboration ?
1414
La dynamique collaborative est critique
La conception d’une API implique toujours de la collaboration
Entre fournisseur et consommateursEntre fournisseur et partenaires / référentiels
Il faut nécessairement cumuler outils et rituels de collaboration
Pour récolter de nouvelles idées et demandesPour arbitrer et prioriser les fonctionnalités à plus forte valeur ajoutéePour fournir des démonstrations et récolter du feedbackPour former et accompagner les équipes
La documentation est clé pour populariser une APIEn particulier une API ouverteHATEOAS est une forme de documentation
15
Conclusion
1616
Une API amène quelques spécificités, mais reste un logiciel
Il est vrai que l’univers des API présente quelques spécificités…
Nécessité de fixer un nouveau vocabulaire avec les équipesCompréhension et exploitation plus poussée du protocole HTTPChoix d’un outillage dédié
Mais fondamentalement une API est un logiciel comme un autre !
Les clés du succès sont les mêmes que pour la majorité des logiciels
Il faut rester proche des consommateursIl faut tester ses idées en prototypantIl faut appliquer les concepts théoriques de manière pragmatiqueIl faut employer un outillage moderne et éprouvéIl faut apprendre de ses erreurs et itérerIl faut mettre en œuvre une collaboration forte entre tous les acteurs
Merci pourvotre attention !
Des questions ?