Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

Thiết lập Google Cloud và OAuth

Bạn có thể truy cập vào Google Health API thông qua Google Cloud. Để bật API và uỷ quyền cho một Tài khoản Google, bạn cần có một dự án trên đám mây của Google.

Cho dù bạn là nhà phát triển API Fitbit hiện tại hay mới sử dụng API Google Health, bạn đều cần hoàn tất bước này để thực hiện các lệnh gọi đến API.

Tạo một dự án và một ứng dụng OAuth

Sử dụng nút Bật API và nhận mã ứng dụng OAuth 2.0 để bật Google Health API và nhận mã ứng dụng OAuth 2.0:

Nếu bạn có một dự án Google Cloud hiện có mà bạn muốn dùng cho Google Health API, hãy nhớ đăng nhập vào tài khoản quản trị của dự án đó trước. Sau đó, hãy chọn dự án hiện có trong danh sách các dự án có sẵn sau khi nhấp vào nút này. Nếu không, hãy tạo một dự án mới.
Chọn Máy chủ web khi thấy câu hỏi "Bạn gọi từ đâu?".
Nhập https://www.google.com làm giá trị cho URI chuyển hướng được uỷ quyền. Bạn phải có URI chuyển hướng để lấy Mã uỷ quyền bằng OAuth 2.0.
Sau khi thiết lập xong, hãy sao chép các giá trị Mã ứng dụng khách và Khoá bí mật của OAuth 2.0, rồi tải JSON thông tin đăng nhập xuống máy cục bộ.

Nếu bạn muốn thiết lập dự án Google Cloud theo cách thủ công hoặc xác minh chế độ thiết lập và truy xuất thông tin đăng nhập của mình một lần nữa, hãy làm như sau:

Bật Google Health API trên trang Bật API.
Nhận mã ứng dụng khách OAuth 2.0 trên trang Thông tin đăng nhập.

Để biết thêm thông tin về cách thiết lập OAuth 2.0 bằng Google Console, hãy xem bài viết Sử dụng OAuth 2.0 để truy cập vào các API của Google.

Thêm người dùng thử nghiệm

Theo mặc định, các ứng dụng OAuth mới tạo sẽ ở trạng thái chưa xác minh với giới hạn 100 người dùng cho cả mục đích kiểm thử và phát hành công khai. Để bật chế độ uỷ quyền trong thời gian này, bạn phải thêm địa chỉ email của từng người dùng vào danh sách Người dùng kiểm thử trong cấu hình dự án theo cách thủ công.

Cập nhật danh sách người dùng thử nghiệm trên trang Đối tượng:

Trên trang này, bạn sẽ thấy "Trạng thái xuất bản" được đặt thành Kiểm thử và "Loại người dùng" được đặt thành Bên ngoài.
Trong phần "Người dùng kiểm thử", hãy nhấp vào + Thêm người dùng. Nhập địa chỉ email của mọi người dùng thử cần được phép cấp cho ứng dụng của bạn quyền truy cập vào dữ liệu sức khoẻ của họ.
Nhấp vào Lưu.

Để hỗ trợ hơn 100 người dùng bằng Google Health API, bạn cần hoàn tất quy trình đánh giá bảo mật của bên thứ ba. Bạn có thể xem thêm thông tin trong Trung tâm trợ giúp về quy trình xác minh ứng dụng OAuth.

Thêm phạm vi

Bạn phải chỉ định các phạm vi mà ứng dụng khách của bạn được phép gọi trên trang Truy cập dữ liệu:

Trên trang này, hãy nhấp vào Thêm hoặc xoá phạm vi.
Trong cột API, hãy tìm "Google Health API". Chọn các phạm vi bạn cần cho ứng dụng của mình.
Sau khi chọn tất cả các phạm vi bạn cần, hãy nhấp vào Cập nhật để quay lại trang Truy cập dữ liệu.
Nhấp vào Lưu.

Trước khi chọn phạm vi, hãy xem xét việc triển khai phạm vi.

Bạn đã hoàn tất việc thiết lập mã ứng dụng và giờ đây, bạn có thể thực hiện các lệnh gọi đến Google Health API.

Cập nhật phạm vi

Bạn có thể nhắc người dùng uỷ quyền lại cho ứng dụng của mình bằng cách đặt tham số prompt thành consent trong yêu cầu xác thực. Khi prompt=consent được đưa vào, màn hình xin phép sẽ xuất hiện mỗi khi ứng dụng của bạn yêu cầu uỷ quyền cho các phạm vi truy cập, ngay cả khi tất cả các phạm vi đã được cấp cho dự án API Google của bạn trước đó.

Để thêm hoặc thay đổi phạm vi bằng cách sử dụng tham số prompt=consent, hãy làm theo các bước sau:

Xác định danh sách đầy đủ Phạm vi mà ứng dụng của bạn cần. Bạn nên thêm cả các phạm vi hiện có và mọi phạm vi mới cần thêm.
Sửa đổi tham số phạm vi trong URL uỷ quyền để thêm danh sách các giá trị phạm vi được phân tách bằng dấu cách đã cập nhật.
Thêm prompt=consent vào các tham số URI xác thực của bạn. Thao tác này buộc máy chủ uỷ quyền nhắc người dùng đồng ý trước khi trả về thông tin cho ứng dụng khách của bạn.

Ví dụ sau đây cho thấy một yêu cầu HTTPS GET đến điểm cuối uỷ quyền OAuth 2.0 của Google, yêu cầu nhiều phạm vi có prompt=consent được thêm vào:
```
https://accounts.google.com/o/oauth2/v2/auth?client_id=client-id&redirect_uri=redirect-uri&response_type=code&access_type=offline&scope=https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly%20https://www.googleapis.com/auth/googlehealth.sleep.readonly&prompt=consent
```
Khi người dùng nhấp vào đường liên kết mới, họ sẽ thấy một trang đồng ý liệt kê tất cả các phạm vi được yêu cầu. Sau khi người dùng nhấp vào "Tiếp tục" hoặc "Cho phép", bạn sẽ nhận được một mã uỷ quyền mới có thể được trao đổi để lấy mã thông báo bao gồm toàn bộ các phạm vi.

Chỉ thêm prompt=consent khi cần thiết, chẳng hạn như khi bạn cần lấy mã làm mới mới hoặc khi các phạm vi được yêu cầu đã thay đổi.

Thư viện ứng dụng OAuth2

Bạn có thể xem danh sách các thư viện ứng dụng OAuth2 hiện có được dùng để tích hợp với các khung phổ biến tại Sử dụng OAuth 2.0 để truy cập vào các API của Google.

Mã làm mới

Để duy trì quyền truy cập lâu dài vào các API của Google mà không yêu cầu người dùng liên tục xác thực lại, ứng dụng của bạn phải sử dụng mã làm mới. Để biết thông tin chi tiết toàn diện về cách triển khai, bao gồm cả các yêu cầu và thông số HTTP cụ thể bắt buộc, hãy tham khảo tài liệu về nền tảng nhận dạng của Google.

Để đổi mã làm mới lấy mã truy cập, hãy thực hiện lệnh gọi HTTPS POST đến điểm cuối mã thông báo Google OAuth 2.0. Đoạn mã sau đây cho thấy một ví dụ về yêu cầu và phản hồi:

Yêu cầu

curl -L -X POST 'https://oauth2.googleapis.com/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=client-id&client_secret=client-secret&refresh_token=refresh-token&grant_type=refresh_token'

Phản hồi

{
  "access_token": "access-token",
  "expires_in": 3599,
  "scope": "scope-list",
  "token_type": "Bearer",
  "refresh_token": "refresh-token",
  "refresh_token_expires_in": 112154
}

Thời điểm làm mới mã thông báo

Làm mới mã thông báo làm mới theo yêu cầu trong quá trình diễn ra tự nhiên của một phiên hoạt động của người dùng khi mã thông báo truy cập đã hết hạn hoặc sắp hết hạn. Tránh làm mới mã thông báo theo lô (ví dụ: sử dụng dịch vụ hoặc tác vụ cron theo lịch để làm mới mã thông báo cho tất cả người dùng vào một thời điểm cố định).

Bạn không nên làm mới mã thông báo theo lô vì những lý do sau:

Việc làm mới hàng loạt sẽ ngăn việc điều chỉnh các bản cập nhật mã thông báo theo các mẫu đồng bộ hoá người dùng đang hoạt động. Mặc dù bạn có thể dùng lệnh gọi Get Devices để xem thời gian đồng bộ hoá gần đây nhất của người dùng, nhưng lệnh gọi này yêu cầu một phạm vi OAuth bổ sung mà người dùng không bắt buộc phải phê duyệt.
Xử lý hàng loạt các mã thông báo cập nhật không cần làm mới, gây ra chi phí xử lý dư thừa cho cả hệ thống của bạn và máy chủ của Google.
Nếu xảy ra sự cố mạng hoặc máy chủ ngừng hoạt động trong quá trình làm mới hàng loạt, thì tất cả mã thông báo người dùng bị ảnh hưởng sẽ bị ảnh hưởng cùng một lúc. Việc làm mới từng mã thông báo riêng lẻ trong quá trình đồng bộ hoá người dùng tự nhiên sẽ cô lập tác động của các lỗi tạm thời đối với một người dùng duy nhất.
Việc chẩn đoán vấn đề sẽ khó khăn hơn với các lô công việc. Vì các yêu cầu hàng loạt xảy ra ít thường xuyên hơn và tạo ra hàng loạt mục nhập nhật ký cùng một lúc, nên việc xác định chính xác thời điểm bắt đầu của một sự cố sẽ khó khăn hơn.
Các đợt tăng đột biến về số lượng yêu cầu mã thông báo trong quá trình chạy hàng loạt sẽ làm tăng khả năng đạt đến giới hạn tốc độ hoặc gặp phải lỗi xác thực không liên tục.

Hành vi của mã thông báo trong quá trình thử nghiệm

Lưu ý cách mã làm mới hoạt động tuỳ theo trạng thái xuất bản của dự án Google Cloud:

Chế độ kiểm thử: Nếu màn hình xin phép OAuth của bạn được định cấu hình với trạng thái xuất bản "Kiểm thử", thì mã làm mới được cấp sẽ dựa trên thời gian và hết hạn sau 7 ngày. Trong khoảng thời gian này, bạn sẽ nhận được một mã làm mới duy nhất vẫn hợp lệ và có thể dùng để lấy mã truy cập mới cho đến khi hết hạn.
Chế độ đã xuất bản: Sau khi ứng dụng của bạn chuyển sang trạng thái "Đang phát hành công khai", mã làm mới thường sẽ không hết hạn trừ phi bị thu hồi hoặc không được sử dụng trong một thời gian dài (thường là 6 tháng).

Để đảm bảo trải nghiệm người dùng liền mạch, hãy nhớ xuất bản ứng dụng trước khi chuyển ứng dụng vào môi trường thực tế để tránh trường hợp mã thông báo hết hạn sau 7 ngày.

Bảo vệ nhiều tài khoản (RISC API)

Bật tính năng Chia sẻ và phối hợp rủi ro và sự cố (RISC) nếu bạn muốn nhận được thông báo về các thay đổi đối với mã thông báo sự kiện hoặc hoạt động liên kết tài khoản, chẳng hạn như tài khoản bị ngắt kết nối hoặc mã thông báo bị thu hồi, để dọn dẹp mã thông báo đã lưu trữ và cập nhật trạng thái kết nối giao diện người dùng. Bạn không bắt buộc phải bật API RISC.

Cách bật RISC API cho dự án Google Cloud:

Mở trang RISC API trong Google Cloud Console. Đảm bảo bạn đã chọn dự án mà bạn dùng cho Google Health API.
Đọc Điều khoản RISC và đảm bảo bạn hiểu rõ các yêu cầu.
Nhấp vào Bật nếu bạn đồng ý với các điều khoản.

Sau khi bật API, bạn phải tạo và đăng ký một điểm cuối HTTPS để nhận và xác thực mã thông báo sự kiện do Google gửi.

Để biết thêm thông tin về tính năng Bảo vệ nhiều tài khoản và RISC, hãy xem bài viết Bảo vệ tài khoản người dùng bằng tính năng Bảo vệ nhiều tài khoản.

Thiết lập Google Cloud và OAuth Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.