L'article de Jay Freestone propose une approche pour éviter la duplication des règles métier entre frontend et backend en privilégiant le partage de politiques plutôt que de code. L'idée centrale est que les règles, comme la validation d'état d'une commande, doivent être centralisées côté serveur pour éviter des incohérences lorsque les deux parties évoluent indépendamment. Plutôt que de partager des fonctions ou des modules (risquant des divergences de versions ou de déploiement), l'auteur suggère de transmettre les décisions sous forme de données structurées, comme les actions autorisées ou les raisons de désactivation, permettant au frontend de s'adapter dynamiquement.
L'auteur illustre cette méthode avec un exemple concret : au lieu de dupliquer une fonction canCancelOrder en TypeScript à la fois dans l'API et l'interface, le backend renvoie un objet JSON contenant les actions possibles (allowedActions) et les motifs de désactivation (disabledReasons). Cette approche, inspirée des principes HATEOAS, simplifie la maintenance et garantit la cohérence des règles, tout en restant compatible avec des architectures polyglottes où le partage de code est complexe.
Cet article explore quatre styles architecturaux d'APIs : REST, webhooks, gRPC et HATEOAS. Il explique l'importance cruciale du choix de l'architecture pour la réussite d'une API, impactant l'intégration, la performance et la scalabilité. REST, le plus populaire, est simple, stateless et cacheable, idéal pour les services web standards. Les webhooks, en deuxième position, permettent une communication asynchrone et sont souvent utilisés pour l'automatisation. L'article fournit des exemples concrets et des raisons de choisir chaque style.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Développement d'API hypermedia avec Symfony2 et le bundle créé par l'auteur
HATEOAS = Hypermedia As The Engine Of Application State.... ou comment utiliser au maximum les possibilités de HTTP, cet article est une excellente présentation