Le Blog Amazon Web Services

Construire une API évolutive et sécurisée

Nous espérons que nos précédents articles sur les bonnes pratiques pour vos applications serverless vous ont été utiles. Ce nouvel article se concentre sur les bonnes pratiques et les concepts avec lesquels il faut se familiariser pour ajouter une API dans vos applications. Le premier point compare les architectures APIs de type REST et GraphQL.

Introduction

Les développeurs créent des API RESTful depuis longtemps. Celles-ci utilisent généralement les méthodes HTTP telles que GET, POST, DELETE pour effectuer les opérations. Amazon API Gateway est conçu pour simplifier la création d’API pour les développeurs, quel que soit l’échelle, sans administrer de serveurs, ie serverless. API Gateway s’occupe de toutes les tâches fastidieuses nécessaires comme la gestion du trafic, la sécurité, la surveillance et les changements de versions et d’environnements.

Les API GraphQL sont relativement récentes. Ces API sont conçues pour permettre aux clients de définir la structure des données requêtées en fonction de leurs besoins. AWS AppSync permet de créer des API GraphQL flexibles qui accèdent et associent plusieurs sources de données.

API REST

Construire une API REST consiste à associer des ressources avec des méthodes. Les ressources sont des chemins qui figurent dans l’URL de la requête et les méthodes sont des actions HTTP appliquées sur les ressources. Par exemple, on définit une ressource « cart » :

http://myapi.somecompany.com/cart. La ressource « cart » peut répondre aux requêtes HTTP POST pour ajouter des articles au panier et aux requêtes HTTP GET pour retrouver les articles dans le panier. Le schéma ci-dessous décrit l’architecture de cette API.

L’API Gateway peut être intégrée avec plusieurs ressources en backend afin de fournir une logique de traitement, de stocker la donnée ou bien d’effectuer un processus business. Par exemple, vous pouvez configurer une fonction AWS Lambda pour effectuer l’ajout d’un article dans un panier (HTTP POST). Vous pouvez aussi utiliser l’API Gateway pour interagir directement avec des services AWS tels que DynamoDB. Un exemple consiste à récupérer l’article d’un panier stocké dans DynamoDB (HTTP GET).

Le chemin d’accès (« Path ») et les paramètres de requête (« Query Parameters ») sont utilisés pour injecter des valeurs de manière dynamique via l’API. Par exemple, si on veut retrouver un panier dont l’ID est abcd123, on peut concevoir l’API pour qu’elle supporte un chemin d’accès ou un paramètre de requête qui spécifie l’ID du panier :

/cart?cartId=abcd123 ou /cart/abcd123

Lorsqu’on doit ajouter une fonctionnalité à une API, on crée généralement de nouvelles ressources. Par exemple, pour ajouter une fonction de paiement, on pourrait ajouter une ressource appelée /cart/checkout.

API GraphQL

La conception d’API GraphQL n’est pas structurée autour de ressources et de verbes HTTP. Les API GraphQL nécessitent de définir des types de données et de configurer où les opérations retrouveront la donnée au travers d’un “Resolver”. Une opération correspond soit à une requête soit à une transformation. Les requêtes permettent de récupérer les données ; les transformations permettent de modifier la donnée. Si nous utilisons le même exemple que ci-dessus, nous pouvons définir un panier de la manière suivante :

type Cart {
  cartId: ID!
  customerId: String
  name: String
  email: String
  items: [String]
}

On configure ensuite les champs dans le panier (« cart ») pour les associer à des sources de données. AppSync est alors responsable d’exécuter les « Resolvers » pour obtenir les informations adéquates. Le client enverra des POST HTTP vers le endpoint AppSync avec la forme exacte de la donnée dont il a besoin. AppSync se charge d’exécuter les « Resolvers » configurés permettant d’obtenir les données et d’envoyer une réponse consolidée au client.

Avec GraphQL, le client peut modifier la requête pour spécifier uniquement les données dont il a besoin.

L’exemple ci-dessus montre deux requêtes pour deux ensembles de données différents.
L’objet de la première requête intègre :

  • l’identifiant (customerId), le nom (name) et l’email du client associé à un identifiant panier (cartId)
  • les articles (items) associés à un identifiant panier (cartId).

La deuxième requête est plus restreinte :

  • le nom (name) et l’email du client associé à un identifiant panier (cartId).

Selon la requête, AppSync exécute le(s) bon(s) « Resolver(s) » pour récupérer les données. Dans les deux cas, la requête est soumise via POST HTTP au même endpoint ; seul le corps de la requête diffère.

Comme nous l’avons vu plus haut, une implémentation en API REST aurait nécessité de définir plusieurs ressources et méthodes HTTP ou bien plusieurs chemins d’accès (« Path ») et paramètres de requête (« Query Parameters ») pour fournir les mêmes fonctionnalités.

AppSync fournit par ailleurs d’autres fonctionnalités qui ne sont pas disponibles avec les API REST telles que la synchronisation des données en temps réel et plusieurs méthodes d’authentification au niveau des champs ou des opérations.

Synthèse

Comme vous avez pu l’expérimenté, GraphQL et REST constituent deux approches différentes pour concevoir et délivrer vos API. Dans les articles à venir, nous couvrirons les fonctionnalités spécifiques ainsi que les détails d’architecture recommandés pour choisir entre API Gateway (REST) et AppSync (GraphQL).

Article contribué par Geoge Moa, Solution Architect spécialiste des solution Serverless et traduit par Clément Goillot, Solution Architect des équipes AWS France pour les secteurs Commerce, Media & Entertainment.