

# REL03-BP03 Fournir des contrats de service par API
<a name="rel_service_architecture_api_contracts"></a>

Les contrats de service sont des accords documentés entre API producteurs et consommateurs définis dans une définition lisible par API machine. Une stratégie de gestion des versions des contrats permet aux consommateurs de continuer à utiliser l'existant API et de migrer leurs applications vers une version plus récente API lorsqu'elles sont prêtes. Le déploiement du producteur peut avoir lieu à tout moment tant que le contrat est respecté. Les équipes de service peuvent utiliser la pile technologique de leur choix pour exécuter le API contrat. 

 **Résultat escompté :** les applications conçues avec des architectures orientées services ou microservices sont capables de fonctionner de manière indépendante tout en intégrant une dépendance à l'environnement d'exécution. Les modifications apportées à un API consommateur ou à un producteur n'interrompent pas la stabilité de l'ensemble du système lorsque les deux parties suivent un API contrat commun. Les composants qui communiquent via le service APIs peuvent exécuter des versions fonctionnelles indépendantes, mettre à niveau les dépendances d'exécution ou basculer vers un site de reprise après sinistre (DR) avec peu ou pas d'impact les uns sur les autres. En outre, les services discrets sont capables d’évoluer de manière indépendante en absorbant la demande de ressources sans que les autres services soient réduits horizontalement à l’unisson. 

 **Anti-modèles courants :** 
+  Création d'un service APIs sans schémas fortement typés. Il en résulte APIs que cela ne peut pas être utilisé pour générer des API liaisons et des charges utiles qui ne peuvent pas être validées par programmation. 
+  Ne pas adopter de stratégie de gestion des versions, qui oblige API les consommateurs à effectuer des mises à jour et à publier ou à échouer lorsque les contrats de service évoluent. 
+  Messages d’erreur qui divulguent les détails de l’implémentation du service sous-jacent au lieu de décrire les échecs d’intégration dans le contexte et le langage du domaine. 
+  Ne pas utiliser de API contrats pour développer des scénarios de test et API des mises en œuvre fictives afin de permettre des tests indépendants des composants du service. 

 **Avantages de l'établissement de cette meilleure pratique :** les systèmes distribués composés de composants communiquant par le biais de contrats de API service peuvent améliorer la fiabilité. Les développeurs peuvent détecter les problèmes potentiels dès le début du processus de développement en vérifiant le type lors de la compilation afin de vérifier que les demandes et les réponses respectent le API contrat et que les champs obligatoires sont présents. APIles contrats fournissent une interface autodocumentée claire APIs et fournissent une meilleure interopérabilité entre les différents systèmes et langages de programmation. 

 **Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen 

## Directives d’implémentation
<a name="implementation-guidance"></a>

 Une fois que vous avez identifié les domaines commerciaux et déterminé la segmentation de votre charge de travail, vous pouvez développer votre serviceAPIs. Définissez d'abord des contrats de service lisibles par machine pourAPIs, puis implémentez une stratégie de gestion des API versions. Lorsque vous êtes prêt à intégrer des services via des protocoles courants tels que REST GraphQL ou des événements asynchrones, vous pouvez intégrer des AWS services dans votre architecture afin d'intégrer vos composants à l'aide de contrats bien typés. API 

 **AWS services pour les API contrats de service** 

 Intégrez AWS des services tels qu'[Amazon API Gateway](https://aws.amazon.com/api-gateway/) et [Amazon EventBridge](https://aws.amazon.com/eventbridge/) dans votre architecture pour utiliser des contrats de API service dans votre application. [AWS AppSync](https://aws.amazon.com/appsync/) Amazon API Gateway vous permet d'intégrer directement des AWS services natifs et d'autres services Web. APIGateway prend en charge la [APIspécification Open](https://github.com/OAI/OpenAPI-Specification) et le versionnement. AWS AppSync est un point de terminaison [GraphQL](https://graphql.org/) géré que vous configurez en définissant un schéma GraphQL pour définir une interface de service pour les requêtes, les mutations et les abonnements. Amazon EventBridge utilise des schémas d'événements pour définir des événements et générer des liaisons de code pour vos événements. 

## Étapes d’implémentation
<a name="implementation-steps"></a>
+  Tout d'abord, définissez un contrat pour votreAPI. Un contrat exprimera les capacités d'un API et définira des objets de données et des champs fortement typés pour l'APIentrée et la sortie. 
+  Lorsque vous configurez APIs dans API Gateway, vous pouvez importer et exporter des API spécifications ouvertes pour vos points de terminaison. 
  +  [L'importation d'une API définition ouverte](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifie la création de votre API et peut être intégrée à AWS l'infrastructure sous forme d'outils de code tels que le [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/)et [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/). 
  +  [L'exportation d'une API définition](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifie l'intégration avec API les outils de test et fournit aux consommateurs de services une spécification d'intégration. 
+  Vous pouvez définir et gérer GraphQL AWS AppSync en [définissant APIs un fichier de schéma GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) pour générer votre interface de contrat et simplifier l'interaction avec des REST modèles complexes, plusieurs tables de base de données ou des services existants. 
+  [AWS Amplify](https://aws.amazon.com/amplify/)les projets intégrés AWS AppSync génèrent des fichiers de JavaScript requêtes fortement typés à utiliser dans votre application, ainsi qu'une bibliothèque cliente AWS AppSync GraphQL pour les tables Amazon [DynamoDB](https://aws.amazon.com/dynamodb/). 
+  Lorsque vous consommez des événements de service d'Amazon EventBridge, les événements adhèrent aux schémas qui existent déjà dans le registre des schémas ou que vous définissez avec l'Open API Spec. Avec un schéma défini dans le registre, vous pouvez également générer des liaisons client à partir du contrat de schéma afin d’intégrer votre code aux événements. 
+  Extension ou version de votreAPI. L'extension d'une API est une option plus simple lorsque vous ajoutez des champs qui peuvent être configurés avec des champs facultatifs ou des valeurs par défaut pour les champs obligatoires. 
  +  JSONles contrats basés sur des protocoles tels que REST GraphQL peuvent être une bonne solution pour l'extension de contrat. 
  +  XMLdes contrats basés sur des protocoles tels que SOAP ceux qui devraient être testés auprès des consommateurs de services afin de déterminer la faisabilité d'une prolongation du contrat. 
+  Lors du versionnement d'unAPI, envisagez d'implémenter le versionnage par proxy dans le cadre duquel une façade est utilisée pour prendre en charge les versions afin que la logique puisse être maintenue dans une base de code unique. 
  +  Avec API Gateway, vous pouvez utiliser [les mappages de demandes et de réponses](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) pour simplifier l'absorption des modifications de contrat en établissant une façade pour fournir des valeurs par défaut pour les nouveaux champs ou pour supprimer les champs supprimés d'une demande ou d'une réponse. Avec cette approche, le service sous-jacent peut gérer une base de code unique. 

## Ressources
<a name="resources"></a>

 **Bonnes pratiques associées :** 
+  [REL03-BP01 Choisissez comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP02 Créer des services axés sur des domaines d’activité et la fonctionnalité](rel_service_architecture_business_domains.md) 
+  [REL04-BP02 Implémenter des dépendances faiblement couplées](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP05 Définir les délais d'expiration des clients](rel_mitigate_interaction_failure_client_timeouts.md) 

 **Documents connexes :** 
+ [Qu'est-ce qu'une API (interface de programmation d'applications) ?](https://aws.amazon.com/what-is/api/)
+ [Implémentation de microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Compromis des microservices ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservices : une définition de ce nouveau terme architectural ](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
+ [Utilisation des extensions de API passerelle pour ouvrir API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [Spécification ouverte API](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL : schémas et types ](https://graphql.org/learn/schema/)
+ [liaisons EventBridge de code Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)

 **Exemples connexes :** 
+ [Amazon API Gateway : Configuration d'une application à REST API l'aide d'Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Amazon API Gateway vers l'application Amazon CRUD DynamoDB à l'aide d'Open API](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [Modèles modernes d'intégration des applications à l'ère du sans serveur : intégration des services de API passerelle](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [Implémentation du versionnement des API passerelles basé sur les en-têtes avec Amazon CloudFront](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync : création d’une application client ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)

 **Vidéos connexes :** 
+ [Utilisation d'Open API in AWS SAM pour gérer API Gateway](https://www.youtube.com/watch?v=fet3bh0QA80)

 **Outils associés :** 
+ [APIPasserelle Amazon](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)