Scroll
JSON:API vs. le module REST du cœur
En Bref
Choisissez REST si vous avez des données non entité à exposer. Dans tous les autres cas, choisissez JSON:API.
Un peu plus nuancé :
- Le module REST du cœur permet tout (tout format, toute logique, toute méthode HTTP) et une configurabilité extrême. Puissant mais complexe et donc relativement fragile.
- JSON:API se concentre sur l’exposition de la plus grande force de Drupal (les entités/modèles de données) de façon cohérente. Simple mais suffisamment puissant pour la plupart des cas d’utilisation.
Tableau comparatif des fonctionnalités
| Fonctionnalité | JSON:API | REST | Remarque |
|---|---|---|---|
| Entités exposées comme ressources | ✔️ | ✔️ | REST : nécessite configuration par type d’entité. JSON:API : tout est exposé par défaut. Les deux respectent les accès aux entités. |
| Données personnalisées exposées comme ressources | ✔️ | Écrire des plugins personnalisés @RestResource. JSON:API supporte uniquement les entités. | |
| Récupération de ressources individuelles | ✔️ | ✔️ | |
| Récupération de listes de ressources | ✔️ | En partie | REST : nécessite de configurer une vue et un affichage "REST export". |
| Pagination des listes de ressources | ✔️ | Modules additionnels comme le Pager Serializer sont nécessaires. | REST : non supporté ! Les vues REST export retournent toutes les ressources. |
| Filtrage des listes de ressources | ✔️ | En partie | REST : uniquement si vous créez un filtre exposé pour chaque champ et chaque opérateur possible. |
| Tri des ressources | ✔️ | ||
| Inclusions/embeddings | ✔️ | Seulement en HAL+JSON | |
| Pas d’emballage inutile des valeurs de champs | ✔️ | La normalisation HAL et la normalisation par défaut (et donc tous les formats) exposent exactement les structures PHP en mémoire utilisées par Drupal, ce qui rend l’expérience développeur douloureuse. JSON:API simplifie la normalisation des champs à cardinalité simple et à propriété unique. | |
| Possibilité d’omettre les champs non nécessaires au consommateur | ✔️ | ||
| URLs cohérentes | ✔️ | ||
| Le consommateur peut découvrir les types de ressources disponibles | ✔️ | ||
| Structure de réponse indépendante de Drupal | ✔️ | REST : la normalisation HAL est en théorie sans spécificités Drupal, mais en pratique ce n’est pas le cas. | |
| Bibliothèques clientes | ✔️ | ||
| Spécification extensible | En cours | ||
| Zéro configuration | ✔️ | REST : chaque plugin @RestResource peut être exposé mais doit être configuré pour l’être. Pour chacun, il faut choisir les formats autorisés, les fournisseurs d’authentification permis, et éventuellement les méthodes HTTP autorisées. JSON:API : toutes les entités sont exposées automatiquement, l’accès entité/champ est respecté, tous les fournisseurs d’authentification installés sont autorisés automatiquement. |
Plus d’informations
Voir le motif de l’ajout du module JSON:API au cœur de Drupal, ainsi que le motif architectural du module.
Article extrait de la documentation Drupal.