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.
Une URL de fonction est un point de terminaison HTTP(S) dédié pour votre fonction Lambda. Vous pouvez créer et configurer une URL de fonction via la console Lambda ou l’API Lambda.
Astuce
Lambda propose deux méthodes pour appeler votre fonction via un point de terminaison HTTP : function URLs et Amazon API Gateway. Si vous ne savez pas quelle est la meilleure méthode pour votre cas d'utilisation, consultezSélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP.
Lorsque vous créez une URL de fonction, Lambda génère automatiquement un point de terminaison URL unique pour vous. Une fois que vous avez créé une URL de fonction, son point de terminaison URL ne change jamais. Les points de terminaison URL de fonction ont le format suivant :
https://
<url-id>
.lambda-url.<region>.on.aws
Note
URLs Les fonctions ne sont pas prises en charge dans les pays suivants Régions AWS : Asie-Pacifique (Hyderabadap-south-2
) (), Asie-Pacifique (Melbourneap-southeast-4
) (), Asie-Pacifique (Malaisie) ()ap-southeast-5
, Canada Ouest (Calgary) (ca-west-1
), Europe (Espagne) (), Europe (Zuricheu-south-2
) ()eu-central-2
, Israël (Tel Aviv) () et Moyen-Orient (Émirats arabes unisil-central-1
) (). me-central-1
URLs Les fonctions sont compatibles avec le double empilage, prenant en charge et. IPv4 IPv6 Après avoir configuré votre URL de fonction, vous pouvez invoquer votre fonction à travers son point de terminaison HTTP(S) via un navigateur Web, curl, Postman, ou n’importe quel client HTTP. Pour invoquer l’URL d’une fonction, vous devez avoir des autorisations lambda:InvokeFunctionUrl
. Pour de plus amples informations, veuillez consulter Contrôle d’accès.
Rubriques
Principes de base de l’invocation d’une URL de fonction
Si votre URL de votre fonction utilise le type d’authentification AWS_IAM
, vous devez signer chaque demande HTTP en utilisant AWS Signature Version 4 (SigV4). Des outils tels que Postman
Si vous n’utilisez pas d’outil pour signer des demandes HTTP sur l’URL de votre fonction, vous devez signer manuellement chaque demande à l’aide de SigV4. Lorsque l’URL de votre fonction reçoit une demande, Lambda calcule également la signature SigV4. Lambda traite la demande uniquement si les signatures correspondent. Pour obtenir des instructions sur la façon de signer manuellement vos demandes avec SigV4, voir Signature des AWS demandes avec signature version 4 du Référence générale d'Amazon Web Services guide.
Si l’URL de votre fonction utilise le type d’authentification NONE
, vous n’avez pas besoin de signer vos demandes avec SigV4. Vous pouvez invoquer votre fonction via un navigateur Web, curl, Postman ou n’importe quel client HTTP.
Pour tester des demandes GET
simples vers votre fonction, utilisez un navigateur web. Par exemple, si l’URL de votre fonction est https://abcdefg.lambda-url.us-east-1.on.aws
, et si elle prend en compte un paramètre de chaîne message
, l’URL de votre demande peut se présenter comme suit :
https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld
Pour tester d’autres demandes HTTP, telles qu’une demande POST
, vous pouvez utiliser un outil tel que curl. Par exemple, si vous souhaitez inclure certaines données JSON dans une demande POST
pour l’URL de votre fonction, vous pouvez utiliser la commande curl suivante :
curl -v 'https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld' \ -H 'content-type: application/json' \ -d '{ "example": "test" }'
Charges utiles de demandes et de réponses
Lorsqu’un client appelle l’URL de votre fonction, Lambda mappe la demande sur un objet événement avant de la transmettre à votre fonction. La réponse de votre fonction est ensuite mappée à une réponse HTTP que Lambda renvoie au client via l’URL de la fonction.
Les formats d’événements de demande et de réponse suivent le même schéma que le format de charge utile version 2.0 d’Amazon API Gateway.
Format de la charge utile de demande
Une charge utile de demande a la structure suivante :
{
"version": "2.0",
"routeKey": "$default",
"rawPath": "/my/path",
"rawQueryString": "parameter1=value1¶meter1=value2¶meter2=value",
"cookies": [
"cookie1",
"cookie2"
],
"headers": {
"header1": "value1",
"header2": "value1,value2"
},
"queryStringParameters": {
"parameter1": "value1,value2",
"parameter2": "value"
},
"requestContext": {
"accountId": "123456789012",
"apiId": "<urlid>",
"authentication": null,
"authorizer": {
"iam": {
"accessKey": "AKIA...",
"accountId": "111122223333",
"callerId": "AIDA...",
"cognitoIdentity": null,
"principalOrgId": null,
"userArn": "arn:aws:iam::111122223333:user/example-user",
"userId": "AIDA..."
}
},
"domainName": "<url-id>.lambda-url.us-west-2.on.aws",
"domainPrefix": "<url-id>",
"http": {
"method": "POST",
"path": "/my/path",
"protocol": "HTTP/1.1",
"sourceIp": "123.123.123.123",
"userAgent": "agent"
},
"requestId": "id",
"routeKey": "$default",
"stage": "$default",
"time": "12/Mar/2020:19:03:58 +0000",
"timeEpoch": 1583348638390
},
"body": "Hello from client!",
"pathParameters": null,
"isBase64Encoded": false,
"stageVariables": null
}
Paramètre | Description | Exemple |
---|---|---|
|
La version du format de la charge utile pour cet événement. La fonction Lambda prend URLs actuellement en charge le format de charge utile version 2.0. |
|
|
Fonction : URLs n'utilisez pas ce paramètre. Lambda le définit sur |
|
|
Chemin d’accès de la demande. Par exemple, si l’URL de la demande est |
|
|
La chaîne brute contenant les paramètres de la chaîne de la requête de la demande. Les caractères pris en charge sont les suivants : |
|
|
Un tableau contenant tous les cookies envoyés dans le cadre de la demande. |
|
|
La liste des en-têtes de demande, présentée sous forme de paires valeur-clé. |
|
|
Paramètres de requête pour la demande. Par exemple, si l’URL de la demande est |
|
|
Un objet qui contient des informations supplémentaires sur la demande, comme |
|
|
Compte AWS ID du propriétaire de la fonction. |
|
|
L’identifiant de l’URL de la fonction. |
|
|
Fonction : URLs n'utilisez pas ce paramètre. Lambda le définit sur |
|
|
Un objet qui contient des informations sur l’identité de l’appelant si l’URL de la fonction utilise le type d’authentification |
|
|
La clé d’accès de l’identité de l’appelant. |
|
|
Compte AWS Identifiant de l'identité de l'appelant. |
|
|
L’ID (ID d’utilisateur) de l’appelant. |
|
|
Fonction : URLs n'utilisez pas ce paramètre. Lambda le définit sur |
|
|
L’ID de l’organisation du principal associé à l’ID de l’appelant. |
|
|
L’Amazon Resource Name (ARN) utilisateur de l’identité de l’appelant. |
|
|
L’identifiant utilisateur de l’identité de l’appelant. |
|
|
Le nom de domaine de l’URL de la fonction. |
|
|
Le nom de domaine de l’URL de la fonction. |
|
|
Un objet qui contient des informations sur la demande HTTP. |
|
|
La méthode HTTP utilisée dans cette demande. Les valeurs valides sont les suivantes : |
|
|
Chemin d’accès de la demande. Par exemple, si l’URL de la demande est |
|
|
Le protocole de la demande. |
|
|
L’adresse IP source de la connexion TCP immédiate qui fait la demande. |
|
|
La valeur de l’en-tête de la demande Utilisateur-Agent. |
|
|
L’identifiant de la demande d’invocation. Vous pouvez utiliser cet ID pour suivre les journaux d’invocation liés à votre fonction. |
|
|
Fonction : URLs n'utilisez pas ce paramètre. Lambda le définit sur |
|
|
Fonction : URLs n'utilisez pas ce paramètre. Lambda le définit sur |
|
|
Horodatage de la demande. |
|
|
L’horodatage de la demande, en heure d’époque Unix. |
|
|
Le corps de la demande. Si le type de contenu de la demande est binaire, le corps est codé en base64. |
|
|
Fonction : URLs n'utilisez pas ce paramètre. Lambda le définit sur |
|
|
|
|
|
Fonction : URLs n'utilisez pas ce paramètre. Lambda le définit sur |
|
Format de la charge utile de la réponse
Lorsque votre fonction renvoie une réponse, Lambda analyse la réponse et la convertit en réponse HTTP. Les charges utiles de la réponse de fonction ont le format suivant :
{
"statusCode": 201,
"headers": {
"Content-Type": "application/json",
"My-Custom-Header": "Custom Value"
},
"body": "{ \"message\": \"Hello, world!\" }",
"cookies": [
"Cookie_1=Value1; Expires=21 Oct 2021 07:48 GMT",
"Cookie_2=Value2; Max-Age=78000"
],
"isBase64Encoded": false
}
Lambda déduit le format de réponse pour vous. Si votre fonction renvoie un JSON valide et ne renvoie pas un statusCode
, Lambda assume ce qui suit :
-
statusCode
est200
.Note
statusCode
Les valeurs valides sont comprises entre 100 et 599. -
content-type
estapplication/json
. -
body
est la réponse de la fonction. -
isBase64Encoded
estfalse
.
Les exemples suivants montrent comment la sortie de votre fonction Lambda est mappée à la charge utile de réponse et comment la charge utile de réponse est mappée à la réponse HTTP finale. Lorsque le client invoque l’URL de votre fonction, il voit la réponse HTTP.
Exemple de sortie pour une réponse de chaîne
Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) |
---|---|---|
|
|
|
Exemple de sortie pour une réponse JSON
Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) |
---|---|---|
|
|
|
Exemple de sortie pour une réponse personnalisée
Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) |
---|---|---|
|
|
|
Cookies
Pour renvoyer des cookies depuis votre fonction, n’ajoutez pas manuellement des en-têtes set-cookie
. Incluez plutôt les cookies dans votre objet de charge utile de réponse. Lambda les interprète automatiquement et les ajoute comme en-têtes set-cookie
de votre réponse HTTP, comme dans l’exemple suivant.
Sortie de la fonction Lambda | Réponse HTTP (ce que voit le client) |
---|---|
|
|