View a markdown version of this page

Comparaison de REST et GraphQL - AWS AppSync GraphQL

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comparaison de REST et GraphQL

Les API (interfaces de programmation d'applications) jouent un rôle crucial dans la facilitation de l'échange de données entre les applications. Comme indiqué précédemment, deux approches importantes pour la conception d'API ont vu le jour : GraphQL et REST. Bien que les deux aient pour objectif fondamental de permettre la communication client-serveur, leur mise en œuvre et leurs cas d'utilisation diffèrent considérablement.

GraphQL et REST partagent plusieurs caractéristiques clés :

  1. Client-Server Modèle  : Les deux utilisent une architecture client-serveur pour l'échange de données.

  2. Apatridie  : aucun des deux ne conserve les informations relatives à la session du client entre les demandes.

  3. HTTP-Based: Les deux utilisent généralement HTTP comme protocole de communication sous-jacent.

  4. Resource-Oriented Conception  : les deux conçoivent leur échange de données autour de ressources, qui font référence à toute donnée ou objet auquel le client peut accéder et manipuler via l'API.

  5. Flexibilité du format de données  : JSON est le format d'échange de données le plus couramment utilisé dans les deux cas, bien que d'autres formats tels que XML et HTML soient également pris en charge.

  6. Indépendant du langage et de la base de données  : les deux peuvent fonctionner avec n'importe quel langage de programmation ou structure de base de données, ce qui les rend hautement interopérables.

  7. Prise en charge de la mise en cache  : les deux prennent en charge la mise en cache, permettant aux clients et aux serveurs de stocker les données fréquemment consultées pour améliorer les performances.

Tout en partageant certains principes fondamentaux, GraphQL et REST diffèrent considérablement dans leur approche de la conception d'API et de la récupération de données :

  1. Structure de la demande et récupération des données

    REST utilise différentes méthodes HTTP (GET, POST, PUT, DELETE) pour effectuer des opérations sur les ressources. Cela nécessite souvent plusieurs points de terminaison pour différentes ressources, ce qui peut nuire à l'efficacité de la récupération des données. Par exemple, l'exécution d'une opération GET pour récupérer les données d'un utilisateur peut entraîner une extraction excessive ou insuffisante des données. Pour obtenir les données correctes, une troncature ou plusieurs opérations peuvent être appelées.

    GraphQL utilise un point de terminaison unique pour toutes les opérations. Il s'appuie sur des requêtes pour récupérer des données et des mutations pour modifier les données. Les clients peuvent utiliser des requêtes pour récupérer exactement les données dont ils ont besoin en une seule demande, ce qui réduit la charge réseau en minimisant le transfert de données.

  2. Server-side Schema (Schéma)

    REST ne nécessite pas de schéma côté serveur, bien qu'un schéma puisse être défini en option pour une conception et une documentation d'API efficaces.

    GraphQL utilise un schéma côté serveur fortement typé pour définir les données et les services de données. Le schéma, écrit en langage de définition de schéma GraphQL (SDL), inclut des types d'objets et des champs pour chaque objet, ainsi que des fonctions de résolution côté serveur qui définissent les opérations pour chaque champ.

  3. Contrôle de version

    REST inclut souvent le contrôle de version dans l'URL, ce qui peut entraîner la gestion simultanée de plusieurs versions d'API. La gestion des versions n'est pas obligatoire, mais elle peut permettre d'éviter des modifications majeures.

    GraphQL favorise une évolution continue de l'API sans versionnage explicite en exigeant une rétrocompatibilité. Les champs supprimés renvoient des messages d'erreur, tandis que les balises de dépréciation suppriment progressivement les anciens champs et renvoient des messages d'avertissement.

  4. Gestion des erreurs

    REST est faiblement typé, ce qui nécessite l'intégration de la gestion des erreurs dans le code environnant. Cela peut ne pas identifier automatiquement les erreurs liées au type (par exemple, l'analyse d'un nombre en tant que texte).

    En revanche, GraphQL est fortement typé et nécessite une définition de schéma complète. Cela permet à votre service d'identifier automatiquement de nombreuses erreurs de demande avec un niveau de détail élevé.

  5. Cas d'utilisation

    REST est mieux adapté pour :

    • Des applications plus petites avec des exigences en matière de données moins complexes.

    • Scénarios dans lesquels les données et les opérations sont utilisées de la même manière par tous les clients.

    • Applications ne nécessitant pas de requêtes de données complexes.

    GraphQL est mieux adapté pour :

    • Scénarios à bande passante limitée, où il est crucial de minimiser les demandes et les réponses.

    • Applications comportant plusieurs sources de données qui doivent être combinées sur un seul point de terminaison.

    • Cas où les demandes des clients varient considérablement et nécessitent des structures de réponse différentes.

    Notez qu'il est possible d'utiliser à la fois les API GraphQL et REST au sein d'une même application pour différents domaines de fonctionnalités. En outre, vous pouvez mettre à niveau une API RESTful pour inclure les fonctionnalités GraphQL sans avoir à procéder à une réécriture complète. Consultez Comment créer des résolveurs GraphQL pour les sources de AWS données pour un exemple.