טריגר https.onCall
ב-Cloud Functions הוא טריגר HTTPS עם פורמט ספציפי לבקשה ולתגובה. בקטע הזה מתוארים הפורמטים של הבקשות והתשובות ב-HTTPS שבהן משתמשים ערכות ה-SDK של הלקוח כדי להטמיע את ה-API. המידע הזה יכול להיות שימושי אם אי אפשר לעמוד בדרישות שלכם באמצעות פלטפורמות Android או Apple או ערכות SDK לאינטרנט.
פורמט הבקשה: כותרות
בקשת ה-HTTP לנקודת קצה של טריגר שניתן לקריאה חייבת להיות POST
עם הכותרות הבאות:
- חובה:
Content-Type: application/json
- אפשר להוסיף את הערך
; charset=utf-8
.
- אפשר להוסיף את הערך
- אופציונלי:
Authorization: Bearer <token>
- אסימון מזהה משתמש מסוג Firebase Authentication של המשתמש המקושר שמגיש את הבקשה. הקצה העורפי מאמת את האסימון הזה באופן אוטומטי ועושה אותו זמין ב-
context
של ה-handler. אם האסימון לא תקף, הבקשה תידחה.
- אסימון מזהה משתמש מסוג Firebase Authentication של המשתמש המקושר שמגיש את הבקשה. הקצה העורפי מאמת את האסימון הזה באופן אוטומטי ועושה אותו זמין ב-
- אופציונלי:
Firebase-Instance-ID-Token: <iid>
- אסימון הרישום FCM מ-SDK של הלקוח ב-Firebase. הערך הזה חייב להיות מחרוזת. הוא זמין ב-
context
של הטיפול. היא משמשת לטירגוט התראות.
- אסימון הרישום FCM מ-SDK של הלקוח ב-Firebase. הערך הזה חייב להיות מחרוזת. הוא זמין ב-
- אופציונלי:
X-Firebase-AppCheck: <token>
- האסימון של Firebase App Check שסופק על ידי אפליקציית הלקוח ששולחת את הבקשה. הקצה העורפי מאמת את האסימון הזה באופן אוטומטי ומפענח אותו, ומחדיר את
appId
ל-context
של הטיפול. אם לא ניתן לאמת את האסימון, הבקשה נדחית. (זמין ל-SDK >=3.14.0)
- האסימון של Firebase App Check שסופק על ידי אפליקציית הלקוח ששולחת את הבקשה. הקצה העורפי מאמת את האסימון הזה באופן אוטומטי ומפענח אותו, ומחדיר את
אם כל כותרת אחרת נכללת, הבקשה נדחית, כפי שמתואר במסמכי התשובה שבהמשך.
הערה: בלקוחות JavaScript, הבקשות האלה מפעילות בדיקת קדם OPTIONS
של CORS, כי:
- לא ניתן להפר את המדיניות:
application/json
הערך חייב להיותtext/plain
אוapplication/x-www-form-urlencoded
. - הכותרת
Authorization
היא לא כותרת בקשה ברשימת ההיתרים של CORS. - אסור להשתמש בכותרות אחרות באופן דומה.
הטריגר שניתן לקריאה מטפל באופן אוטומטי בבקשות OPTIONS
האלה.
גוף הבקשה
גוף הבקשה של ה-HTTP צריך להיות אובייקט JSON עם אחד מהשדות הבאים:
- חובה:
data
– הארגומנט המועבר לפונקציה. זה יכול להיות כל ערך JSON חוקי. הנתונים מקודדים באופן אוטומטי לסוגי JavaScript מקומיים בהתאם לפורמט הסריאליזציה שמתואר בהמשך.
אם יש שדות אחרים בבקשה, הקצה העורפי מתייחס לבקשה שאינה תקינה והיא נדחית.
פורמט תגובה: קודי סטטוס
יש כמה מקרים שיכולים לגרום לקודי סטטוס HTTP שונים ולקודי סטטוס מחרוזת שונים של שגיאות בתגובה.
במקרה של שגיאת HTTP לפני ההפעלה של הטריגר
client
, התגובה לא מטופלת כפונקציית לקוח. לדוגמה, אם לקוח מנסה להפעיל פונקציה שלא קיימת, הוא מקבל תגובה מסוג404 Not Found
.אם הטריגר של הלקוח מופעל אבל הבקשה בפורמט שגוי, למשל היא לא בפורמט JSON, אם יש בה שדות לא חוקיים או שחסר בה השדה
data
, הבקשה תידחה עם400 Bad Request
עם קוד השגיאהINVALID_ARGUMENT
.אם אסימון האימות שסופק בבקשה לא תקף, הבקשה תידחה עם
401 Unauthorized
, עם קוד השגיאהUNAUTHENTICATED
.אם טוקן ההרשמה ל-FCM שסופק בבקשה לא תקין, ההתנהגות לא מוגדרת. האסימון לא נבדק בכל בקשה, אלא רק כשמשתמשים בו כדי לשלוח התראה ב-push באמצעות FCM.
אם הטריגר שניתן לקריאה מופעל אבל נכשל בגלל החרגה שלא מטופלת או שהוא מחזיר הבטחה שנכשלה, הבקשה תידחה עם
500 Internal Server Error
עם קוד השגיאהINTERNAL
. כך ניתן למנוע חשיפה בטעות של שגיאות תכנות למשתמשי קצה.אם הפונקציה הניתנת לקריאה מופעלת ומחזירה תנאי שגיאה מפורש באמצעות ה-API שסופק לפונקציות ניתנות לקריאה, הבקשה נכשלת. קוד הסטטוס של ה-HTTP שמוחזר מבוסס על המיפוי הרשמי של סטטוס השגיאה לסטטוס HTTP, כפי שהוא מוגדר ב-code.proto. קוד השגיאה, ההודעה והפרטים הספציפיים שהוחזרו מקודדים בגוף התשובה, כפי שמפורט בהמשך. כלומר, אם הפונקציה מחזירה שגיאה מפורשת עם סטטוס
OK
, לסטטוס התגובה יהיה הערך200 OK
, אבל השדהerror
יוגדר בתגובה.אם הטריגר של הלקוח מצליח, סטטוס התגובה הוא
200 OK
.
פורמט התגובה: כותרות
התגובה כוללת את הכותרות הבאות:
Content-Type: application/json
- אפשר להוסיף את הערך
; charset=utf-8
.
גוף התשובה
התגובה מנקודת קצה של לקוח היא תמיד אובייקט JSON. הוא מכיל לפחות את השדה result
או error
, יחד עם שדות אופציונליים. אם התגובה היא לא אובייקט JSON או שהיא לא מכילה את הערכים data
או error
, ה-SDK של הלקוח צריך להתייחס לבקשה ככישלון עם קוד השגיאה של Google INTERNAL (13)
.
error
– אם השדה הזה מופיע, הבקשה נחשבת כנכשלה, בלי קשר לקוד הסטטוס של ה-HTTP או אם קיים גםdata
. הערך בשדה הזה צריך להיות אובייקט JSON בפורמט הסטנדרטי Google Cloud HTTP Mapping לשגיאות, עם שדות עבורstatus
,message
ו-details
(אופציונלי). השדהcode
לא ייכלל. אם השדהstatus
לא מוגדר או שהוא מכיל ערך לא חוקי, הלקוח צריך להתייחס לסטטוס כ-INTERNAL
, בהתאם ל-code.proto. אם השדהdetails
קיים, הוא נכלל בכל פרטי המשתמש שמצורפים לשגיאה ב-SDK של הלקוח, אם רלוונטי.
הערה: השדהdetails
כאן הוא ערך שמסופק על ידי המשתמש. היא לא חייבת להיות רשימה של ערכים שמקושרים לפי סוג אב, כמו בפורמטStatus
של Google.result
– הערך שהפונקציה מחזירה. הוא יכול להיות כל ערך JSON חוקי. ה-SDK של firebase-functions מקודד באופן אוטומטי את הערך שהמשתמש מחזיר לפורמט JSON הזה. ערכות ה-SDK של הלקוח מפענחות את הפרמטרים האלה באופן אוטומטי לסוגים מקומיים בהתאם לפורמט הסריאליזציה שמתואר בהמשך.
אם יש שדות אחרים, צריך להתעלם מהם.
סריאליזציה
פורמט הסדרת הנתונים במטענים ייעודיים (payloads) שרירותיים זהה גם לבקשה וגם לתשובה.
כדי לשמור על עקביות בפלטפורמה, הם מקודדים ב-JSON כאילו הם הערך של השדה Any
במאגר פרוטוקול proto3, באמצעות מיפוי JSON סטנדרטי. ערכים של סוגים פשוטים כמו null
, int
, double
או string
מקודדים ישירות ולא כוללים את הסוג המפורש שלהם. לכן, float
ו-double
מקודדים באותו אופן, ויכול להיות שלא תדעו איזה מהם מתקבל בצד השני של השיחה. בסוגים שאינם מותאמים ל-JSON, נעשה שימוש בקידוד proto3 מוקלד של הערך. למידע נוסף, עיינו במסמכי התיעוד של כל קידוד JSON.
מותר להשתמש בסוגי הקבצים הבאים:
- null –
null
- int (signed או unsigned, עד 32 ביט) – לדוגמה,
3
או-30
. - float – לדוגמה,
3.14
- כפול – לדוגמה,
3.14
- בוליאני –
true
אוfalse
- מחרוזת – לדוגמה,
"hello world"
- map<string, any=""> – לדוגמה,
{"x": 3}
</string,> - list
– לדוגמה, [1, 2, 3]
- long (signed או unsigned, עד 64 ביט) – [פרטים נוספים מופיעים בהמשך]
אין תמיכה בערכים NaN
ו-Infinity
עבור float
ו-double
.
הערה: long
הוא סוג מיוחד שאסור בדרך כלל ב-JSON, אבל הוא מכוסה במפרט של proto3. לדוגמה, הערכים האלה מקודדים כך:
long
{
'@type': 'type.googleapis.com/google.protobuf.Int64Value',
'value': '-123456789123456'
}
unsigned long
{
'@type': 'type.googleapis.com/google.protobuf.UInt64Value',
'value': '123456789123456'
}
באופן כללי, המפתח @type
צריך להיחשב שמור, ולא לשמש למפות שהועברו.
מאחר שהסוג לא מצוין לסוגי נתונים פשוטים, ערכים מסוימים ישנו את הסוג שלהם אחרי שהם יועברו. float
שהוענק הופך ל-double
. short
הופך ל-int
, וכן הלאה. ב-Android, ערכי הרשימות נתמכים גם ב-List
וגם ב-JSONArray
. במקרים כאלה, העברה של JSONArray תניב List
.
אם מתבצעת סריאליזציה של מפה עם שדה @type
לא ידוע, היא נשארת כמפה. כך המפתחים יכולים להוסיף שדות עם סוגים חדשים לערכי ההחזרה שלהם בלי לשבור לקוחות ישנים יותר.
דוגמאות קוד
הדוגמאות בקטע הזה ממחישות איך לקודד את הנתונים הבאים:
- דוגמה מסוג callable.call ב-Swift
- התקבלה תגובה מוצלחת לשיחה
- תגובה של כשל לשיחה
דוגמה ל-Callable.call ב-Swift לקידוד
callable.call([
"aString": "some string",
"anInt": 57,
"aFloat": 1.23,
"aLong": -123456789123456 as Int64
])
כותרת הבקשה:
Method: POST
Content-Type: application/json; charset=utf-8
Authorization: Bearer some-auth-token
Firebase-Instance-ID-Token: some-iid-token
גוף הבקשה:
{
"data": {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23,
"aLong": {
"@type": "type.googleapis.com/google.protobuf.Int64Value",
"value": "-123456789123456"
}
}
}
תגובה לקידוד
return {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23
};
כותרת תגובה מוצלחת:
200 OK
Content-Type: application/json; charset=utf-8
גוף התגובה במקרה של הצלחה:
{
"response": {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23
}
}
תגובה של כשל בקידוד
throw new HttpsError("unauthenticated", "Request had invalid credentials.", {
"some-key": "some-value"
});
כותרת התגובה שנכשלה:
401 UNAUTHENTICATED
Content-Type: application/json; charset=utf-8
גוף התשובה שנכשלה:
{
"error": {
"message": "Request had invalid credentials.",
"status": "UNAUTHENTICATED",
"details": {
"some-key": "some-value"
}
}
}