Création d'objets dans le cycle de vie de l'API

Table des matières

• Table des matières
• Préface
• Introduction
  • Pourquoi les entités sont-elles mauvaises pour la désérialisation ?
  • La solution
  • Schéma de réponse/demande API
• Utilisation du DTO
• Modèle de constructeur
  • Exemple de constructeur
  • Composition du constructeur
  • Plus de compositions
• Réponse et demande
• Conclusion

Préface

Cet article se compose de deux parties. La première partie est une introduction au problème et une présentation d'une solution architecturale. La deuxième partie présente une solution finale sous forme de bundle Symfony basée sur les connaissances de la première partie.

Introduction

L'une des tâches d'une API consiste à gérer la communication entre les clients et les points de terminaison. Cela signifie la sérialisation et la désérialisation des données et la gestion de ces données dans la logique métier backend. Il s’agit maintenant de choisir où désérialiser votre JSON vers et vers l’arrière. En travaillant dans un petit projet, vous utiliserez probablement directement des entités pour la désérialisation. Ce sera très bien d'utiliser également des groupes de sérialisation pour les quelques entités. Mais lorsque vous travaillez dans un grand projet avec de nombreuses entités et points de terminaison d'API, les utiliser pour la désérialisation est une mauvaise décision.

Pourquoi les entités sont-elles mauvaises pour la désérialisation ?

Pour un projet plus important, l'utilisation d'entités pour cette tâche présente des inconvénients évidents :

• Le premier inconvénient de l’utilisation d’entités comme réponse API est que coupler le schéma de base de données au schéma de réponse API est une mauvaise décision architecturale. Vous perdrez la flexibilité. Les modifications de schéma d’un côté ou de l’autre seront propagées de l’autre côté.
• Garder un œil sur différents groupes sera pénible.
  • J'ai vu des projets dans lesquels une entité était impliquée dans de nombreuses réponses de points de terminaison d'API. Chaque réponse doit présenter une forme différente de l’entité. Il a donc fallu environ cinq groupes pour construire différentes réponses à cette entité. Si vous imaginez aussi que ces groupes sont ensuite répartis entre d'autres entités qui sont liées à celle-ci et utilisées dans d'autres réponses de endpoints, vous comprendrez que gérer ces groupes et les surveiller est vraiment une grande aventure.
• Et le dernier est bien sûr le gros désordre dans vos entités concernant la quantité de méta données à contrôler : ORM, Sérialisation et probablement validation.
  • Si vous utilisez OpenAPI (Swagger...
    [Courte citation de 8% de l'article original]