Concevoir son développement par l'API
Et si nous commencions par l'API ? Et ensuite ? Quelles bonnes pratiques pour concevoir une API sur de bonnes bases ?
Other
Salle inconnue
Il existe de nombreuses approches xxx-first, de mobile-first à content-first en passant par user-first, vous aurez compris le principe.
Et si vos données étaient découplées de votre interface ? N'est-ce pas suffisant pour poser une API à partir de là ? Et si nous faisions plutôt un API-first ?
Le fait de commencer votre application par son API permet de se poser beaucoup de questions sur vos données et la façon dont vous allez les exposer de façon pérenne : pour les utilisateurs, pour les divers périphériques, pour les développeurs, pour les moteurs de recherche, pour un usage interne, etc.
Nous pourrons faire un mobile-first ensuite, nous n'aurons plus qu'à penser à l'interface, le reste étant déjà mature.
Ça c'est la première étape, maintenant il est temps de construire cette API. Si vous croyez ne pas en être là, relisez le début : Il est temps de construire une API.
L'API publiée vous n'en contrôlez plus les clients et faire évoluer les bases n'est pas évident. Ce que vous construisez est là pour longtemps. Quelles sont les retours d'expériences et bonnes pratiques pour ne pas se prendre les pieds dans le tapis ?
Vous avez certainement déjà entendu parler de REST mais les choses sont plus complexes que ça. Comment gérer les évolutions et les versions de l'API ? les formats en entrée et en sortie ? les variations et paramètres d'une même ressources ? les relations entre ressources ? la sécurité ? l'authentification ? la gestion des erreurs ? la pagination ? l'i18n et l10n ?
Plus généralement, nous partons avec pour objectif premier de concevoir une API le plus tôt possible, avec des bases solides mais les plus simples possible. Nous allons parler de tout ça, autant pour échanger nos idées que pour vous faire part du retour d'expérience pratique.
