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.
# Configuration d’une méthode à l’aide de la console API Gateway
Lorsque vous créez une méthode à l’aide de la console d’API REST, vous configurez à la fois la demande d’intégration et la demande de méthode. Par défaut, API Gateway crée la réponse de méthode `200` de votre méthode.
Les instructions suivantes expliquent comment modifier les paramètres de requête de méthode et comment créer des réponses de méthode supplémentaires pour votre méthode.
**Topics**
+ [Modification d’une demande de méthode API Gateway dans la console API Gateway](#how-to-method-settings-callers-console)
+ [Configuration d’une réponse de méthode API Gateway à l’aide de la console API Gateway](#how-to-method-response-settings-console)
## Modification d’une demande de méthode API Gateway dans la console API Gateway
Ces instructions supposent que vous avez déjà créé votre demande de méthode. Pour plus d’informations sur la création d’une méthode, consultez [Configuration d’une demande d’intégration d’API à l’aide de la console API Gateway](how-to-method-settings-console.md).
1. Dans le volet **Ressources**, choisissez votre méthode, puis l’onglet **Demande de méthode**.
1. Dans la section **Paramètres de requête de méthode**, choisissez **Modifier**.
1. Pour **Autorisation**, sélectionnez un mécanisme d’autorisation disponible.
1. Pour activer l’accès ouvert à la méthode pour n’importe quel utilisateur, choisissez **Aucun**. Cette étape peut être ignorée si le paramètre par défaut n’a pas été modifié.
1. Pour utiliser les autorisations IAM afin de contrôler l’accès client à la méthode, sélectionnez `AWS_IAM`. Avec ce choix, seuls les utilisateurs des rôles IAM avec la bonne politique IAM attachée sont autorisés à appeler cette méthode.
Pour créer le rôle IAM, spécifiez une stratégie d’accès dans un format similaire à ce qui suit :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": [
"arn:aws:execute-api:us-east-1:111111111111:aaabbb/*/GET/"
]
}
]
}
```
------
Dans cette stratégie d’accès, `arn:aws:execute-api:us-east-1:111111111111:aaabbb/*/GET/` est l’ARN de votre méthode. Vous pouvez trouver l’ARN de votre méthode en sélectionnant la méthode sur la page **Ressources**. Pour en savoir plus sur la définition d’autorisations IAM, consultez [Contrôle de l’accès à une API REST avec des autorisations IAM](permissions.md).
Pour créer le rôle IAM, vous pouvez adapter les instructions du didacticiel [Création d’une fonction Lambda pour l’intégration Lambda autre que de proxy](getting-started-lambda-non-proxy-integration.md#getting-started-new-lambda).
1. Pour utiliser un mécanisme d’autorisation Lambda, sélectionnez un jeton ou un mécanisme d’autorisation de demande. Créez un mécanisme d’autorisation Lambda pour que ce choix s’affiche dans le menu déroulant. Pour plus d’informations sur la création d’un mécanisme d’autorisation Lambda, consultez [Utilisation des mécanismes d’autorisation Lambda API Gateway](apigateway-use-lambda-authorizer.md).
1. Pour utiliser un groupe d’utilisateurs Amazon Cognito, choisissez un groupe d’utilisateurs disponible sous **Cognito user pool authorizers (Mécanismes d’autorisation du groupe d’utilisateurs Cognito)**. Créez un groupe d’utilisateurs dans Amazon Cognito, ainsi qu’un mécanisme d’autorisation de groupe d’utilisateurs Amazon Cognito dans API Gateway pour que ce choix s’affiche dans le menu déroulant. Pour plus d’informations sur la manière de créer un mécanisme d’autorisation de groupe d’utilisateurs Amazon Cognito, consultez [Contrôlez l'accès à REST APIs en utilisant les groupes d'utilisateurs Amazon Cognito comme autorisateur](apigateway-integrate-with-cognito.md).
1. Pour spécifier la validation des demandes, sélectionnez une valeur dans le menu déroulant **Validateur de demande**. Pour désactiver la validation des demandes, sélectionnez **Aucune**. Pour plus d’informations concernant chaque option, consultez [Demande de validation pour REST APIs dans API Gateway](api-gateway-method-request-validation.md).
1. Sélectionnez **Clé d’API obligatoire** pour exiger une clé d’API. Lorsque cette option est activée, les clés d’API sont utilisées dans les [plans d’utilisation](api-gateway-api-usage-plans.md) afin de limiter le trafic client.
1. (Facultatif) Pour attribuer un nom d’opération dans un kit SDK Java de cette API généré par API Gateway, entrez un nom pour **Nom de l’opération**. Par exemple, pour la demande de méthode `GET /pets/{petId}`, le nom d’opération du kit SDK Java est, par défaut, `GetPetsPetId`. Ce nom est créé à partir du verbe HTTP der la méthode (`GET`) et des noms de variables du chemin de la ressource (`Pets` et `PetId`). Si vous définissez le nom de l’opération en tant que `getPetById`, le nom d’opération du kit SDK devient `GetPetById`.
1. Pour ajouter un paramètre de chaîne de requête à la méthode, procédez comme suit :
1. Choisissez **Paramètres de chaîne de requête d’URL**, puis **Ajouter une chaîne de requête**.
1. Pour **Nom**, entrez le nom du paramètre de chaîne de requête.
1. Sélectionnez **Obligatoire** si le paramètre de chaîne de requête récemment créé doit être utilisé pour une validation de demande. Pour plus d'informations sur la validation de demande, consultez [Demande de validation pour REST APIs dans API Gateway](api-gateway-method-request-validation.md).
1. Sélectionnez **Mise en cache** si le paramètre de chaîne de requête récemment créé doit être utilisé dans le cadre d’une clé de mise en cache. Pour plus d'informations sur la mise en cache, consultez [Utilisation de paramètres de méthode ou d’intégration en tant que clés de cache pour indexer les réponses mises en cache](api-gateway-caching.md#enable-api-gateway-cache-keys).
Pour supprimer le paramètre de chaîne de requête, choisissez **Supprimer**.
1. Pour ajouter un paramètre d’en-tête à la méthode, procédez comme suit :
1. Choisissez **En-têtes de demande HTTP**, puis **Ajouter un en-tête**.
1. Pour **Nom**, entrez le nom de l’en-tête.
1. Sélectionnez **Obligatoire** si l’en-tête récemment créé doit être utilisé pour une validation de demande. Pour plus d'informations sur la validation de demande, consultez [Demande de validation pour REST APIs dans API Gateway](api-gateway-method-request-validation.md).
1. Sélectionnez **Mise en cache** si l’en-tête récemment créé doit être utilisé dans le cadre d’une clé de mise en cache. Pour plus d'informations sur la mise en cache, consultez [Utilisation de paramètres de méthode ou d’intégration en tant que clés de cache pour indexer les réponses mises en cache](api-gateway-caching.md#enable-api-gateway-cache-keys).
Pour supprimer l’en-tête, choisissez **Supprimer**.
1. Pour déclarer le format de charge utile d’une demande de méthode avec le verbe HTTP `POST`, `PUT` ou `PATCH`, choisissez **Corps de la demande** et procédez comme suit :
1. Choisissez **Add model**.
1. Pour **Content-Type**, entrez un type MIME (par exemple, `application/json`).
1. Pour **Modèle**, sélectionnez un modèle dans le menu déroulant. Les modèles disponibles actuellement pour l’API incluent les modèles `Empty` et `Error` par défaut, ainsi que tous les modèles que vous avez créés et ajoutés à la collection [Models](https://docs.aws.amazon.com/apigateway/latest/api/API_Model.html) de l’API. Pour plus d’informations sur la création d’un modèle, consultez [Modèles de données pour REST APIs](models-mappings-models.md).
**Note**
Le modèle est utile pour informer le client du format de données prévu pour une charge utile. Il permet également de générer un modèle de mappage squelettique. Il est important de générer un kit SDK fortement typé de l’API dans des langages comme Java, C\$1, Objective-C et Swift. Ceci est nécessaire uniquement si la validation de demande est activée pour la charge utile.
1. Choisissez **Enregistrer**.
## Configuration d’une réponse de méthode API Gateway à l’aide de la console API Gateway
Une méthode d’API peut avoir un ou plusieurs réponses. Chaque réponse est indexée selon son code de statut HTTP. Par défaut, la console API Gateway ajoute la réponse `200` aux réponses de méthode. Vous pouvez modifier cela, par exemple pour que la méthode renvoie plutôt la réponse `201`. Vous pouvez ajouter d’autres réponses, par exemple, `409` en cas d’accès refusé et `500` si des variables d’étape non initialisées sont utilisées.
Pour utiliser la console API Gateway pour modifier, supprimer ou ajouter une réponse à une méthode d’API, suivez les instructions suivantes.
1. Dans le volet **Ressources**, choisissez votre méthode, puis l’onglet **Réponse de méthode**. Vous devrez peut-être choisir la flèche droite pour afficher l'onglet.
1. Dans la section **Paramètres de réponse de la méthode**, choisissez **Créer une réponse**.
1. Pour **Code de statut HTTP**, entrez un code de statut HTTP, tel que `200`, `400` ou `500`.
Lorsqu’une réponse renvoyée par le backend n’a pas de méthode de réponse correspondante définie, API Gateway échoue à renvoyer la réponse au client. Au lieu de cela, une réponse d’erreur `500 Internal server error` est renvoyée.
1. Sélectionnez **Add header**.
1. Pour **Nom de l’en-tête**, entrez un nom.
Pour renvoyer un en-tête du backend au client, ajoutez-le dans la réponse de la méthode.
1. Choisissez **Ajouter un modèle** pour définir un format pour le corps de la réponse de méthode.
Entrez le type de média de la charge utile de la réponse pour **Type de contenu** et choisissez un modèle dans le menu déroulant **Modèles**.
1. Choisissez **Enregistrer**.
Pour modifier une réponse existante, accédez à la réponse de votre méthode, puis choisissez **Modifier**. Pour modifier le **Code de statut HTTP**, choisissez **Supprimer** et créez une nouvelle méthode de réponse.
Pour chaque réponse renvoyée par le backend, vous devez disposer d’une réponse compatible configurée comme réponse de méthode. Toutefois, le modèle de charge utile et d’en-têtes de réponse de méthode de configuration sont facultatifs, sauf si vous mappez le résultat à partir du backend à la réponse de méthode avant de revenir au client. De plus, un modèle de charge utile de réponse de méthode est important si vous générez un kit SDK fortement typé pour votre API.