Quelle est la différence entre OData, JsonAPI, GraphQL?
J'ai utilisé OData dans ma carrière un peu et maintenant peu de mes collègues de différentes équipes ont recommandé que nous passions à JsonAPI et GraphQL car ce n'est pas lié à Microsoft. Je n'ai pas beaucoup d'expérience dans ces deux langages de requête. Autant que je sache, OData est un standard utilisé par Salesforce, IBM, Microsoft et il est très mature. Pourquoi devrait-on passer à JsonAPI et/ou GraphQL? Y a-t-il un réel avantage? JsonAPI et GraphQL sont-ils de nouveaux standards? Changer les implémentations de l'API publique en fonction de la popularité semble inutile, surtout lorsqu'il n'y a pas de gros avantages.
Quelqu'un peut-il m'éclairer?
OData est une spécification similaire à l'API JSON. Les deux décrivent une norme pour la création et la consommation d'API RESTful. GraphQL est une nouvelle approche de la conception d'API et spécifie une manière différente d'interroger les ressources d'API.
OData : Conçu et développé chez Microsoft depuis 2007, normalisé par le consortium OASIS . La dernière version V4 est soumise à ISO/IEC JTC 1 pour approbation en tant que norme internationale. Les sociétés du comité technique (TC) incluent CA Technologies, Citrix, IBM, Microsoft, Progress, Red Hat, SAP et SDL.
Il existe un certain nombre de bibliothèques pour les langages de programmation populaires - .NET, Java, JavaScript, PHP et Ruby. La spécification permet des ressources dynamiques et il existe un document de service qui répertorie tous les points de terminaison API pour les clients à découvrir De plus, il existe un document de métadonnées décrivant le schéma.
API JSON : l'API JSON a été initialement rédigée par Yehuda Katz en mai 2013. Cette première version a été extraite du transport JSON implicitement défini par Ember Data REST adapter. La version stable actuelle de la spécification est 1. . La spécification de l'API JSON est implémentée pour la majorité des langages de programmation, pour les deux côté client et côté serveur.
L'API JSON prend en charge HATEOAS via la propriété
linkdans le document JSON. Les autres fonctionnalités incluent la pagination, le tri, le filtrage et les relations. Les documents JSON produits par les serveurs API JSON sont très détaillés avec beaucoup de propriétés imbriquées.GraphQL : Développé chez Facebook depuis 2015. Le spécification est toujours un brouillon de travail. Il est assez populaire parmi les fans de React et est principalement utilisé en combinaison avec React ou Vue.js. Similaire à GraphQL, Falcor est également relativement nouveau).
Bien que GraphQL utilise HTTP, il n'est pas considéré comme REST, mais plutôt comme une alternative à REST. Au lieu de cela, il utilise un modèle de requête/réponse dans un seul document JSON (virtuel). Ce nouveau modèle est un peu plus agréable à utiliser pour les développeurs, mais ses avantages par rapport à REST sont discutables. Étant donné son jeune âge, l'écosystème n'a pas encore mûri.
Par souci de clarté et d'exhaustivité, j'inclurai OpenAPI dans la liste, bien qu'il ne s'agisse pas exactement d'une spécification API. Cela peut être déroutant pour certaines personnes. La norme OpenAPI est une norme indépendante du langage pour décrire et définir les API. Votre API peut suivre l'une des normes ci-dessus (à l'exception de GraphQL) et également être documentée à l'aide de Swagger 3, par exemple.
- OpenAPI (a.k.a. Swagger) : Développé dans le cadre de OpenAPI Initiative et de la Linux Foundation. Pris en charge par de grandes entreprises technologiques comme Google, Microsoft, IBM, SAP, Oracle, Ebay et Paypal. La version actuelle de la spécification est .0.2 . Il existe des implémentations pour la majorité des langages de programmation, ainsi que de nombreux outils supplémentaires comme les générateurs d'interface utilisateur Web, etc.
La meilleure chose que vous obtenez avec des spécifications comme Swagger est l'outillage qui les entoure - générateurs pour les pages de documentation API, générateurs pour le code SDK client, etc.
Cette norme est probablement la plus utilisée aujourd'hui pour la documentation de l'API et la génération de code. Il est également pris en charge par les fournisseurs de cloud comme Amazon Web Services dans leur passerelle API (v2 uniquement).
Mon opinion personnelle:
Comme vous pouvez le voir, il existe plusieurs spécifications RESTful, plutôt qu'une seule norme universelle. Je suis d'accord avec xumix ici - ils semblent tous souffrir du syndrome "Not Invented Here". Les avantages de choisir l'une des options ci-dessus sont faibles, surtout si votre projet est de petite ou moyenne taille. La spécification implémentée par votre API est-elle importante? Probablement pas beaucoup. Concentrez-vous simplement sur la création d'une API cohérente et bien documentée.