Présentation pour le Meetup Paris API du 28/04/2016 sur les API "Design-First".

1. Meetup Paris API
API « Design First » : Pourquoi et Comment
28 Avril 2016 @Mangopay
Alexandre ESTELA
aestela@palo-it.com
@alx_estela

2. 2
C’est l’histoire d’un développeur et coach…
Java
Agile

3. 3
Au commencement étaient les Web Services SOAP

4. 4
Un jour vinrent les API REST

5. POURQUOI
l’approche “Code First”
est peu adaptée
pour les API

6. 6
Le design de l’API est une phase essentielle
Design FonctionnelDesign Technique
Granularité des
ressources
Attributs
Types & Enums
Validation
Relations & Héritage
Le design de l’API doit d’abord satisfaire vos
consommateurs techniques et fonctionnels
URIs & Verbes
Media Types
Sécurité
Performance
Versioning
HATEOAS

7. 7
L’approche « Code First » présente des limites
Limite de
personnalisation
du contrat d’API
généré
Limite de la
collaboration avec
les consommateurs
(fonctionnels
notamment)

8. EN QUOI
l’approche “Design First”
est davantage adaptée
pour les API

9. 9
Une API « Design First » n’est pas influencée par son implémentation
Couche API
Liberté de Design Technique ET Fonctionnel
Couche Implémentation
Application(s)
API Gateway
Middleware…
Groupe de
consommateurs
Groupe de
consommateurs
Groupe de
consommateurs

10. 10
Une API « Design First » encourage la collaboration
Version de
contrat d’API
Change
Request

11. COMMENT
l’approche “Design First”
peut être mise en oeuvre
pour une API

12. 12
Les outils de design & de co-design d’API s’améliorent

13. 13
Les outils pour lier contrat et implémentation évoluent
https://github.com/swagger-api/swagger-inflector (Java)
https://github.com/swagger-api/swagger-node (Node.js)
https://github.com/zalando/connexion (Python)
Scan du
contrat de l’API
Implémentation
générée (mock)
Implémentation
codée et associée
Prise en charge de la validation, sécurité,
sérialisation, documentation, versioning…

14. 14
Les rituels de collaboration guident leur mise en œuvre
Continuous
Delivery
Sprint
Planning
Démonstrations
Autre rituel
régulier de
revue

15. 15
Le Design Collaboratif de l’API devient un process continu
Design d’une
nouvelle version
d’API
Soumission du
draft d’API
mockée + doc
Revue de la
nouvelle version
d’API
Implémentation
et déploiement
des évolutions
Mesure de
l’usage
(quanti + quali)

16. Conclusion

17. 17
API = Application Programming Interface
Générer son API, c’est potentiellement être guidé par l’implémentation
Le design de l’API doit être pensé et optimisé pour les consommateurs
Cela requiert des outils « Design First » et des rituels de collaboration
Adoption de l’API
Importance
du Design
de l’API
Démarrage

18. Merci pour votre attention