Un déclencheur https.onCall pour Cloud Functions est un déclencheur HTTPS avec un format spécifique pour la requête et la réponse. Cette section fournit une spécification des formats de requête et de réponse HTTPS utilisés par les SDK client pour implémenter l'API. Ces informations peuvent vous être utiles si vos exigences ne peuvent pas être satisfaites à l'aide des SDK pour Android, Apple ou le Web.
Format de la requête : en-têtes
La requête HTTP envoyée à un point de terminaison de déclencheur appelable doit être une requête POST avec les en-têtes suivants :
- Obligatoire :
Content-Type: application/json- Un
; charset=utf-8facultatif est autorisé.
- Un
- Facultatif :
Authorization: Bearer <token>- Jeton d'ID utilisateur Firebase Authentication pour l'utilisateur connecté qui effectue la requête. Le backend valide automatiquement ce jeton et le met à disposition dans le
contextdu gestionnaire. Si le jeton n'est pas valide, la requête est refusée.
- Jeton d'ID utilisateur Firebase Authentication pour l'utilisateur connecté qui effectue la requête. Le backend valide automatiquement ce jeton et le met à disposition dans le
- Facultatif :
Firebase-Instance-ID-Token: <iid>- Jeton d'enregistrement FCM provenant du SDK client Firebase. Il doit s'agir d'une chaîne. Cette option est disponible dans le
contextdu gestionnaire. Il est utilisé pour cibler les notifications push.
- Jeton d'enregistrement FCM provenant du SDK client Firebase. Il doit s'agir d'une chaîne. Cette option est disponible dans le
- Facultatif :
X-Firebase-AppCheck: <token>- Jeton Firebase App Check fourni par l'application cliente à l'origine de la requête. Le backend valide et décode automatiquement ce jeton, en injectant le
appIddans lecontextdu gestionnaire. Si le jeton ne peut pas être validé, la requête est rejetée. (Disponible pour le SDK >=3.14.0)
- Jeton Firebase App Check fourni par l'application cliente à l'origine de la requête. Le backend valide et décode automatiquement ce jeton, en injectant le
Si d'autres en-têtes sont inclus, la requête est refusée, comme décrit dans la documentation sur les réponses ci-dessous.
Remarque : Dans les clients JavaScript, ces requêtes déclenchent une vérification préliminaire CORS OPTIONS, car :
application/json: non autorisé. Elle doit être définie surtext/plainouapplication/x-www-form-urlencoded.- L'en-tête
Authorizationn'est pas un en-tête de requête CORS-safelisted. - Les autres en-têtes ne sont pas non plus autorisés.
Le déclencheur appelable gère automatiquement ces requêtes OPTIONS.
Corps de la requête
Le corps de la requête HTTP doit être un objet JSON comportant l'un des champs suivants :
- Obligatoire :
data: argument transmis à la fonction. Il peut s'agir de n'importe quelle valeur JSON valide. Il est automatiquement décodé en types JavaScript natifs selon le format de sérialisation décrit ci-dessous.
Si d'autres champs sont présents dans la requête, le backend considère que la requête est mal formée et la rejette.
Format de réponse : codes d'état
Plusieurs cas peuvent entraîner différents codes d'état HTTP et codes d'état de chaîne pour les erreurs dans la réponse.
En cas d'erreur HTTP avant l'appel du déclencheur
client, la réponse n'est pas traitée comme une fonction client. Par exemple, si un client tente d'appeler une fonction inexistante, il reçoit une réponse404 Not Found.Si le déclencheur client est appelé, mais que la requête n'est pas au bon format (par exemple, si elle n'est pas au format JSON, si elle comporte des champs non valides ou si le champ
dataest manquant), la requête est rejetée avec400 Bad Requestet le code d'erreurINVALID_ARGUMENT.Si le jeton d'authentification fourni dans la requête n'est pas valide, la requête est rejetée avec le code d'erreur
UNAUTHENTICATEDet le message401 Unauthorized.Si le jeton d'enregistrement FCM fourni dans la requête n'est pas valide, le comportement n'est pas défini. Le jeton n'est pas vérifié à chaque requête, sauf lorsqu'il est utilisé pour envoyer une notification push avec FCM.
Si le déclencheur appelable est invoqué, mais échoue avec une exception non gérée ou renvoie une promesse ayant échoué, la requête est rejetée avec
500 Internal Server Erroret un code d'erreurINTERNAL. Cela permet d'éviter que les erreurs de codage ne soient accidentellement exposées aux utilisateurs finaux.Si le callable est appelé et renvoie une condition d'erreur explicite à l'aide de l'API fournie pour les fonctions callable, la requête échoue. Le code d'état HTTP renvoyé est basé sur le mappage officiel de l'état d'erreur à l'état HTTP, tel que défini dans code.proto. Le code d'erreur, le message et les détails spécifiques renvoyés sont encodés dans le corps de la réponse, comme indiqué ci-dessous. Cela signifie que si la fonction renvoie une erreur explicite avec l'état
OK, la réponse a l'état200 OK, mais le champerrorest défini dans la réponse.Si le déclencheur client fonctionne, l'état de la réponse est
200 OK.
Format de réponse : en-têtes
La réponse comporte les en-têtes suivants :
Content-Type: application/json- Un
; charset=utf-8facultatif est autorisé.
Corps de la réponse
La réponse d'un point de terminaison client est toujours un objet JSON. Il contient au minimum result ou error, ainsi que tous les champs facultatifs. Si la réponse n'est pas un objet JSON ou ne contient pas data ni error, le SDK client doit considérer la requête comme ayant échoué avec le code d'erreur Google INTERNAL (13).
error: si ce champ est présent, la requête est considérée comme ayant échoué, quel que soit le code d'état HTTP ou la présence dedata. La valeur de ce champ doit être un objet JSON au format standard Google Cloud HTTP Mapping pour les erreurs, avec des champs pourstatus,messageet (facultativement)details. Le champcodene doit pas être inclus. Si le champstatusn'est pas défini ou s'il contient une valeur incorrecte, le client doit traiter l'état commeINTERNAL, conformément à code.proto. Sidetailsest présent, il est inclus dans les informations utilisateur associées à l'erreur dans le SDK client, le cas échéant.
Remarque : Le champdetailsest une valeur fournie par l'utilisateur. Il ne s'agit pas nécessairement d'une liste de valeurs indexées par type proto, comme dans le formatStatusde Google.result: valeur renvoyée par la fonction. Il peut s'agir de n'importe quelle valeur JSON valide. Le SDK firebase-functions encode automatiquement la valeur renvoyée par l'utilisateur dans ce format JSON. Les SDK clients décodent automatiquement ces paramètres en types natifs selon le format de sérialisation décrit ci-dessous.
Si d'autres champs sont présents, ils doivent être ignorés.
Sérialisation
Le format de sérialisation des charges utiles de données arbitraires est le même pour la requête et la réponse.
Pour assurer la cohérence de la plate-forme, ces valeurs sont encodées au format JSON comme si elles étaient la valeur d'un champ Any dans un tampon de protocole proto3, à l'aide du mappage JSON standard. Les valeurs de types simples tels que null, int, double ou string sont encodées directement et n'incluent pas leur type explicite. Ainsi, float et double sont encodés de la même manière, et vous ne savez pas lequel est reçu à l'autre bout de l'appel. Pour les types qui ne sont pas natifs de JSON, l'encodage proto3 typé de la valeur est utilisé. Pour en savoir plus, consultez la documentation sur l'encodage JSON Any.
Les types suivants sont autorisés :
- null -
null - int (signé ou non signé, jusqu'à 32 bits) : par exemple,
3ou-30. - float (par exemple,
3.14) - double : par exemple,
3.14 - booléen :
trueoufalse - chaîne (par exemple,
"hello world") - map<string, any=""> - e.g.
{"x": 3}</string,> - list
: par exemple, [1, 2, 3] - long (signé ou non signé, jusqu'à 64 bits) : [voir ci-dessous pour plus d'informations]
Les valeurs NaN et Infinity pour float et double ne sont pas acceptées.
Notez que long est un type spécial qui n'est normalement pas autorisé dans JSON, mais qui est couvert par la spécification proto3. Par exemple, les valeurs suivantes sont encodées comme suit :
long
{
'@type': 'type.googleapis.com/google.protobuf.Int64Value',
'value': '-123456789123456'
}
unsigned long
{
'@type': 'type.googleapis.com/google.protobuf.UInt64Value',
'value': '123456789123456'
}
En général, la clé @type doit être considérée comme réservée et ne doit pas être utilisée pour les cartes transmises.
Étant donné que le type n'est pas spécifié pour les types simples, certaines valeurs changeront de type après avoir été transmises sur le réseau. Un float transmis devient un double. Un short devient un int, et ainsi de suite. Dans Android, List et JSONArray sont acceptés pour les valeurs de liste. Dans ce cas, la transmission d'un JSONArray générera un List.
Si une carte avec un champ @type inconnu est désérialisée, elle est laissée telle quelle. Cela permet aux développeurs d'ajouter des champs avec de nouveaux types à leurs valeurs de retour sans casser les anciens clients.
Exemples de code
Les exemples de cette section montrent comment encoder les éléments suivants :
- Exemple de callable.call en Swift
- Réponse de réussite pour l'appel
- Réponse d'échec pour l'appel
Exemple de Callable.call en Swift pour encoder
callable.call([
"aString": "some string",
"anInt": 57,
"aFloat": 1.23,
"aLong": -123456789123456 as Int64
])
En-tête de requête :
Method: POST
Content-Type: application/json; charset=utf-8
Authorization: Bearer some-auth-token
Firebase-Instance-ID-Token: some-iid-token
Corps de la requête :
{
"data": {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23,
"aLong": {
"@type": "type.googleapis.com/google.protobuf.Int64Value",
"value": "-123456789123456"
}
}
}
Réponse à encoder
return {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23
};
En-tête de réponse réussie :
200 OK
Content-Type: application/json; charset=utf-8
Corps de réponse en cas de réussite :
{
"response": {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23
}
}
Réponse d'échec à encoder
throw new HttpsError("unauthenticated", "Request had invalid credentials.", {
"some-key": "some-value"
});
En-tête de réponse en cas d'échec :
401 UNAUTHENTICATED
Content-Type: application/json; charset=utf-8
Corps de la réponse ayant échoué :
{
"error": {
"message": "Request had invalid credentials.",
"status": "UNAUTHENTICATED",
"details": {
"some-key": "some-value"
}
}
}