Trình kích hoạt https.onCall
cho Cloud Function là trình kích hoạt HTTPS có định dạng cụ thể cho yêu cầu và phản hồi. Phần này cung cấp thông số kỹ thuật cho các định dạng phản hồi và yêu cầu HTTPS được sử dụng bởi SDK máy khách để triển khai API. Thông tin này có thể hữu ích cho bạn nếu các yêu cầu của bạn không thể được đáp ứng bằng nền tảng Android, Apple hoặc SDK web.
Định dạng yêu cầu: tiêu đề
Yêu cầu HTTP tới điểm cuối kích hoạt có thể gọi được phải là POST
với các tiêu đề sau:
- Bắt buộc:
Content-Type: application/json
- Một tùy chọn
; charset=utf-8
được cho phép.
- Một tùy chọn
- Tùy chọn:
Authorization: Bearer <token>
- Mã thông báo ID người dùng Xác thực Firebase dành cho người dùng đã đăng nhập thực hiện yêu cầu. Chương trình phụ trợ tự động xác minh mã thông báo này và cung cấp mã thông báo này trong
context
của trình xử lý. Nếu mã thông báo không hợp lệ, yêu cầu sẽ bị từ chối.
- Mã thông báo ID người dùng Xác thực Firebase dành cho người dùng đã đăng nhập thực hiện yêu cầu. Chương trình phụ trợ tự động xác minh mã thông báo này và cung cấp mã thông báo này trong
- Tùy chọn:
Firebase-Instance-ID-Token: <iid>
- Mã thông báo đăng ký FCM từ SDK máy khách Firebase. Đây phải là một chuỗi. Điều này có sẵn trong
context
của trình xử lý. Nó được sử dụng để nhắm mục tiêu thông báo đẩy.
- Mã thông báo đăng ký FCM từ SDK máy khách Firebase. Đây phải là một chuỗi. Điều này có sẵn trong
- Tùy chọn:
X-Firebase-AppCheck: <token>
- Mã thông báo Kiểm tra ứng dụng Firebase được cung cấp bởi ứng dụng khách đưa ra yêu cầu. Chương trình phụ trợ tự động xác minh mã thông báo này và giải mã nó, đưa
appId
vàocontext
của trình xử lý. Nếu mã thông báo không thể được xác minh, yêu cầu sẽ bị từ chối. (Có sẵn cho SDK >=3.14.0)
- Mã thông báo Kiểm tra ứng dụng Firebase được cung cấp bởi ứng dụng khách đưa ra yêu cầu. Chương trình phụ trợ tự động xác minh mã thông báo này và giải mã nó, đưa
Nếu bao gồm bất kỳ tiêu đề nào khác, yêu cầu sẽ bị từ chối, như được mô tả trong tài liệu phản hồi bên dưới.
Lưu ý: Trong ứng dụng khách JavaScript, các yêu cầu này kích hoạt đèn chiếu trước CORS OPTIONS
, bởi vì:
-
application/json
không được phép. Nó phải làtext/plain
hoặcapplication/x-www-form-urlencoded
. - Tiêu đề
Authorization
không phải là tiêu đề yêu cầu được liệt kê trong danh sách an toàn của CORS . - Các tiêu đề khác không được phép tương tự.
Trình kích hoạt có thể gọi tự động xử lý các yêu cầu OPTIONS
này.
cơ thể yêu cầu
Phần thân của yêu cầu HTTP phải là một đối tượng JSON với bất kỳ trường nào sau đây:
- Bắt buộc:
data
- Đối số được truyền cho hàm. Đây có thể là bất kỳ giá trị JSON hợp lệ nào. Điều này được tự động giải mã thành các loại JavaScript gốc theo định dạng tuần tự hóa được mô tả bên dưới.
Nếu có bất kỳ trường nào khác có trong yêu cầu, chương trình phụ trợ sẽ xem xét yêu cầu không đúng định dạng và yêu cầu bị từ chối.
Định dạng phản hồi: mã trạng thái
Có một số trường hợp có thể dẫn đến mã trạng thái HTTP và mã trạng thái chuỗi khác nhau do lỗi trong phản hồi.
Trong trường hợp xảy ra lỗi HTTP trước khi kích hoạt
client
được gọi, phản hồi không được xử lý như một chức năng của ứng dụng khách. Ví dụ: nếu một máy khách cố gắng gọi một chức năng không tồn tại, nó sẽ nhận được phản hồi404 Not Found
.Nếu trình kích hoạt ứng dụng khách được gọi, nhưng yêu cầu có định dạng sai, chẳng hạn như không phải là JSON, có trường không hợp lệ hoặc thiếu trường
data
, thì yêu cầu sẽ bị từ chối với400 Bad Request
, với mã lỗi làINVALID_ARGUMENT
.Nếu mã thông báo xác thực được cung cấp trong yêu cầu không hợp lệ, yêu cầu sẽ bị từ chối với
401 Unauthorized
, với mã lỗi làUNAUTHENTICATED
.Nếu mã thông báo đăng ký FCM được cung cấp trong yêu cầu không hợp lệ, hành vi sẽ không được xác định. Mã thông báo không được kiểm tra trên mọi yêu cầu, ngoại trừ khi nó được sử dụng để gửi thông báo đẩy bằng FCM.
Nếu trình kích hoạt có thể gọi được gọi nhưng không thành công với một ngoại lệ chưa được xử lý hoặc trả về một lời hứa không thành công, yêu cầu sẽ bị từ chối với
500 Internal Server Error
, với mã lỗi làINTERNAL
. Điều này ngăn các lỗi mã hóa vô tình bị lộ cho người dùng cuối.Nếu hàm có thể gọi được gọi và trả về một tình trạng lỗi rõ ràng bằng cách sử dụng API được cung cấp cho các hàm có thể gọi được, thì yêu cầu đó sẽ không thành công. Mã trạng thái HTTP được trả về dựa trên ánh xạ chính thức của trạng thái lỗi sang trạng thái HTTP, như được định nghĩa trong code.proto . Mã lỗi, thông báo và thông tin chi tiết cụ thể được trả về được mã hóa trong nội dung phản hồi như chi tiết bên dưới. Điều này có nghĩa là nếu hàm trả về một lỗi rõ ràng với trạng thái
OK
thì phản hồi có trạng thái200 OK
nhưng trườngerror
được đặt trong phản hồi.Nếu trình kích hoạt máy khách thành công, trạng thái phản hồi là
200 OK
.
Định dạng phản hồi: tiêu đề
Phản hồi có các tiêu đề sau:
-
Content-Type: application/json
- Một tùy chọn
; charset=utf-8
được cho phép.
nội dung phản hồi
Phản hồi từ điểm cuối máy khách luôn là một đối tượng JSON. Ở mức tối thiểu, nó chứa result
hoặc error
, cùng với bất kỳ trường tùy chọn nào. Nếu phản hồi không phải là đối tượng JSON hoặc không chứa data
hoặc error
, thì SDK máy khách sẽ coi yêu cầu là không thành công với mã lỗi Google INTERNAL (13)
.
-
error
- Nếu có trường này, thì yêu cầu được coi là không thành công, bất kể mã trạng thái HTTP haydata
cũng có. Giá trị của trường này phải là một đối tượng JSON ở định dạng Google Cloud HTTP Mapping tiêu chuẩn để tìm lỗi, với các trường dành chostatus
,message
và (tùy chọn)details
. Trườngcode
sẽ không được bao gồm. Nếu trườngstatus
không được đặt hoặc là một giá trị không hợp lệ, ứng dụng khách sẽ coi trạng thái làINTERNAL
, theo code.proto . Nếu códetails
chi tiết, thì thông tin đó sẽ được bao gồm trong bất kỳ thông tin người dùng nào được đính kèm với lỗi trong SDK máy khách, nếu có.
Lưu ý: Trườngdetails
ở đây là giá trị do người dùng cung cấp. Nó không nhất thiết phải là danh sách các giá trị được khóa bởi loại proto như ở định dạng GoogleStatus
. -
result
- Giá trị được trả về bởi hàm. Đây có thể là bất kỳ giá trị JSON hợp lệ nào. SDK chức năng firebase tự động mã hóa giá trị do người dùng trả về thành định dạng JSON này. SDK máy khách tự động giải mã các thông số này thành các loại gốc theo định dạng tuần tự hóa được mô tả bên dưới.
Nếu có các trường khác, chúng nên được bỏ qua.
Tuần tự hóa
Định dạng tuần tự hóa cho tải trọng dữ liệu tùy ý là giống nhau cho cả yêu cầu và phản hồi.
Đối với tính nhất quán của nền tảng, chúng được mã hóa bằng JSON như thể chúng là giá trị của trường Any
trong bộ đệm giao thức proto3, sử dụng ánh xạ JSON tiêu chuẩn . Giá trị của các loại đơn giản như null
, int
, double
hoặc string
được mã hóa trực tiếp và không bao gồm loại rõ ràng của chúng. Vì vậy, float
và double
được mã hóa theo cùng một cách và bạn có thể không biết cái nào được nhận ở đầu bên kia của cuộc gọi. Đối với các loại không có nguồn gốc từ JSON, mã hóa proto3 đã nhập cho giá trị được sử dụng. Để biết thêm thông tin, hãy xem tài liệu về Mã hóa JSON bất kỳ .
Các loại sau đây được cho phép:
- vô giá trị -
null
- int (đã ký hoặc chưa ký, tối đa 32 bit) - ví dụ:
3
hoặc-30
. - nổi - ví dụ:
3.14
- gấp đôi - ví dụ
3.14
- boolean -
true
hayfalse
- chuỗi - ví dụ:
"hello world"
- bản đồ
- ví dụ {"x": 3}
- danh sách
- ví dụ [1, 2, 3]
- dài (đã ký hoặc chưa ký, tối đa 64 bit) - [xem bên dưới để biết chi tiết]
Các giá trị NaN
và Infinity
cho float
và double
không được hỗ trợ.
Lưu ý rằng long
là một loại đặc biệt thường không được phép trong JSON, nhưng được bao phủ bởi đặc tả proto3. Ví dụ: chúng được mã hóa thành:
dài
{
'@type': 'type.googleapis.com/google.protobuf.Int64Value',
'value': '-123456789123456'
}
không dấu dài
{
'@type': 'type.googleapis.com/google.protobuf.UInt64Value',
'value': '123456789123456'
}
Nói chung, khóa @type
nên được coi là dành riêng và không được sử dụng cho các bản đồ được chuyển vào.
Bởi vì loại không được chỉ định cho các loại đơn giản, một số giá trị sẽ thay đổi loại sau khi chuyển qua dây. Một float
được chuyển vào sẽ trở thành double
. Một short
trở thành một int
, v.v. Trong Android, cả List
và JSONArray
đều được hỗ trợ cho các giá trị danh sách. Trong những trường hợp đó, việc chuyển vào một JSONArray sẽ mang lại một List
.
Nếu một bản đồ có trường @type
không xác định được giải tuần tự hóa, nó sẽ được để lại dưới dạng bản đồ. Điều này cho phép nhà phát triển thêm các trường có loại mới vào giá trị trả về của chúng mà không làm hỏng ứng dụng khách cũ hơn.
mẫu mã
Các mẫu trong phần này minh họa cách mã hóa như sau:
- Một ví dụ callable.call trong Swift
- Phản hồi thành công cho cuộc gọi
- Phản hồi thất bại cho cuộc gọi
Callable.call ví dụ trong Swift để mã hóa
callable.call([
"aString": "some string",
"anInt": 57,
"aFloat": 1.23,
"aLong": -123456789123456 as Int64
])
Tiêu đề yêu cầu:
Method: POST
Content-Type: application/json; charset=utf-8
Authorization: Bearer some-auth-token
Firebase-Instance-ID-Token: some-iid-token
Nội dung yêu cầu:
{
"data": {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23,
"aLong": {
"@type": "type.googleapis.com/google.protobuf.Int64Value",
"value": "-123456789123456"
}
}
}
Đáp ứng mã hóa
return {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23
};
Tiêu đề phản hồi thành công:
200 OK
Content-Type: application/json; charset=utf-8
Cơ thể phản hồi thành công:
{
"response": {
"aString": "some string",
"anInt": 57,
"aFloat": 1.23
}
}
Lỗi phản hồi để mã hóa
throw new HttpsError("unauthenticated", "Request had invalid credentials.", {
"some-key": "some-value"
});
Tiêu đề phản hồi không thành công:
401 UNAUTHENTICATED
Content-Type: application/json; charset=utf-8
Nội dung phản hồi không thành công:
{
"error": {
"message": "Request had invalid credentials.",
"status": "UNAUTHENTICATED",
"details": {
"some-key": "some-value"
}
}
}