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 ?


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.


#TALK in French

Eric Daspet

E3D5

Après des années comme développeur web, j'ai un peu changé de métier pour faire de la direction technique et du management. Non ce n'est pas sale, juste un autre rôle dans la même direction.

Par le passé j'ai eu l'occasion de fonder les conférences Paris-Web, co-écrire le livre « PHP 5 avancé » (désormais PHP 7 avancé), co-fonder la plateforme de livres numériques TEA (maintenant Vivlio) et diriger les équipes de La Ruche Qui Dit Oui.

Aujourd'hui j'oriente les équipes de Cozy Cloud, à moitié dans le management et à moitié les mains dans le code. Je parle beaucoup vie privée, responsabilité et éthique, sécurité, et architecture des applications web.


David Larlet

Artisan, geek & citoyen.



Other talks from David, Eric

  • 2020 - Comment fonctionne un gestionnaire de mots de passe ?

    Eric Daspet

    Pas de blabla lu cent fois ailleurs. Nous parlerons cryptographie et architecture d'une implémentation réelle.

    Vous apprendrez tout ce que j'ai moi-même appris en implémentant un gestionnaire de mots de passe compatible avec l'API de Bitwarden.


  • 2019 - Table-ronde : Alternatives éthiques pour ses outils

    Eric Daspet

    Comment et avec quoi s’équiper pour répondre à ses besoins numériques ? Modérateur : Sébastien Deleuze Invités : Éric Daspet, Nina LaPalice Cercy, Arthur Vuillard, Samira Rabaâoui, Antoine Duparay, Tristan Nitot


  • 2018 - Plan de vol : Ground Control to Major Tom

    Eric Daspet

    Qu’est-ce que tu voudras faire quand tu seras grand ? La société nous met la pression pour des plans de vol tout tracés. On oublie parfois de prendre un peu de recul et on se retrouve alors en plein vol à se demander si on ne s’est pas planté de destination.

    Nous allons parler, entre autres, de titres de cartes de visites et de rôles réels, de gestion de carrière et d’objectifs personnels, mais aussi d’apprentissage et de formation, de bien-être, de plaisir, de contrôle et de lâcher-prise.


  • 2016 - Simplicité par défaut

    David Larlet

    Allumer une télévision : 3s, démarrer une voiture : 2s, lancer votre micro-onde : 1s. Utiliser votre application ? Intégrer quelqu'un dans votre équipe ? Permettre à une personne externe de participer à votre projet open-source ?