Ủy quyền
Tất cả các yêu cầu đối với API Thư viện Google Photos phải do người dùng đã xác thực cấp phép.
Chi tiết của quy trình cấp phép cho OAuth 2.0 có khác nhau đôi chút tuỳ thuộc về loại ứng dụng mà bạn đang viết. Quy trình chung sau đây áp dụng cho tất cả các loại ứng dụng:
- Chuẩn bị cho quy trình cấp phép bằng cách thực hiện những việc sau:
- Đăng ký ứng dụng của bạn bằng Bảng điều khiển API của Google.
- Kích hoạt API Thư viện và truy xuất thông tin chi tiết về OAuth, chẳng hạn như mã ứng dụng khách và mật khẩu ứng dụng khách. Để biết thêm thông tin, hãy xem Bắt đầu
- Để truy cập dữ liệu người dùng, ứng dụng sẽ gửi yêu cầu tới Google về việc phạm vi truy cập cụ thể.
- Google hiển thị màn hình xin phép người dùng, trong đó yêu cầu họ cấp quyền để yêu cầu một số dữ liệu của họ.
- Nếu người dùng đồng ý, Google sẽ cung cấp cho ứng dụng một mã truy cập sẽ hết hạn sau một khoảng thời gian ngắn.
- Ứng dụng yêu cầu dữ liệu người dùng, đính kèm mã truy cập đối với yêu cầu.
- Nếu xác định rằng yêu cầu và mã thông báo là hợp lệ, Google sẽ trả về dữ liệu được yêu cầu.
Để xác định phạm vi nào phù hợp với ứng dụng của bạn, hãy xem phần Cấp phép các phạm vi.
Quy trình đối với một số loại đơn đăng ký bao gồm các bước bổ sung, chẳng hạn như sử dụng làm mới mã để lấy mã truy cập mới. Để biết thông tin chi tiết về quy trình cho nhiều loại ứng dụng, hãy xem phần Sử dụng OAuth 2.0 để truy cập Google API.
Lưu vào bộ nhớ đệm
Luôn làm mới dữ liệu.
Nếu bạn cần lưu trữ tạm thời nội dung nghe nhìn (chẳng hạn như hình thu nhỏ, ảnh hoặc video) vì lý do hiệu suất, đừng lưu vào bộ nhớ đệm quá 60 phút đối với mỗi lần sử dụng nguyên tắc.
Bạn cũng không nên lưu trữ baseUrls vì mã này sẽ hết hạn sau khoảng 60
phút.
Mã mục nội dung đa phương tiện và mã album giúp nhận dạng duy nhất nội dung trong thư viện của người dùng được miễn khỏi hạn chế lưu vào bộ nhớ đệm. Bạn có thể lưu trữ các mã nhận dạng này vô thời hạn (tuân theo chính sách quyền riêng tư trong ứng dụng của bạn). Sử dụng ID mục nội dung nghe nhìn và ID album để truy xuất lại dữ liệu và URL có thể truy cập bằng cách sử dụng các điểm cuối thích hợp. Cho để biết thêm thông tin, hãy xem phần Tải nội dung nghe nhìn mục hoặc Trang thông tin album.
Nếu có nhiều mục nội dung đa phương tiện cần làm mới, bạn nên lưu trữ tham số tìm kiếm trả về các mục nội dung đa phương tiện và gửi lại truy vấn để tải lại .
Truy cập SSL
Tất cả yêu cầu dịch vụ web của API thư viện đều phải sử dụng HTTPS URL sau:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Các yêu cầu thực hiện qua HTTP đều bị từ chối.
Xử lý lỗi
Để biết thông tin về cách xử lý các lỗi được API trả về, hãy xem bài viết Đám mây Xử lý API "lỗi..
Thử lại các yêu cầu không thành công
Khách hàng nên thử lại trên 5xx lỗi bằng thuật toán thời gian đợi luỹ thừa như mô tả trong
Thời gian đợi luỹ thừa. Độ trễ tối thiểu phải là 1 s
trừ khi được ghi nhận khác.
Đối với 429 lỗi, ứng dụng có thể thử lại với độ trễ tối thiểu là 30s. Đối với tất cả các lựa chọn khác
lỗi, có thể không áp dụng được thử lại. Đảm bảo yêu cầu của bạn không thay đổi và xem
thông báo lỗi để được hướng dẫn.
Thuật toán thời gian đợi luỹ thừa
Trong một số ít trường hợp, có thể xảy ra sự cố khi xử lý yêu cầu của bạn.Bạn có thể nhận được
Mã phản hồi HTTP 4XX hoặc 5XX, hoặc kết nối TCP có thể bị lỗi ở đâu đó
giữa máy khách của bạn và máy chủ của Google. Thông thường, bạn nên thử lại
của bạn. Yêu cầu nối tiếp có thể thành công khi yêu cầu ban đầu không thành công. Tuy nhiên,
điều quan trọng là không được lặp lại, liên tục gửi yêu cầu đến máy chủ của Google. Chiến dịch này
hành vi lặp lại có thể làm quá tải mạng giữa ứng dụng khách của bạn và Google cũng như
gây ra vấn đề cho nhiều bên.
Cách tốt hơn là thử lại với độ trễ tăng dần giữa các lần thử. Thông thường, độ trễ sẽ tăng lên bằng hệ số nhân với mỗi lần thử, một phương pháp tiếp cận được gọi là Hàm số mũ thời gian đợi.
Bạn cũng nên cẩn thận để đảm bảo rằng sẽ không có mã thử lại cao hơn trong ứng dụng chuỗi lệnh gọi dẫn đến các yêu cầu lặp lại liên tiếp nhanh chóng.
Sử dụng lịch sự các API của Google
Các ứng dụng API được thiết kế kém có thể đặt nhiều tải hơn mức cần thiết cho cả Internet và trên các máy chủ của Google. Phần này trình bày một số phương pháp hay nhất để khách hàng của API. Khi làm theo các phương pháp hay nhất này, bạn có thể tránh ứng dụng bị chặn do vô tình lạm dụng API.
Yêu cầu đã đồng bộ hoá
Một số lượng lớn các yêu cầu được đồng bộ hoá với API của Google có thể trông giống như tấn công Từ chối dịch vụ phân tán (DDoS) nhắm vào cơ sở hạ tầng của Google và được xử lý phù hợp. Để tránh tình trạng này, bạn cần đảm bảo rằng các yêu cầu API được không được đồng bộ hoá giữa các ứng dụng.
Ví dụ: hãy xem xét một ứng dụng hiển thị thời gian trong thời gian hiện tại vùng. Ứng dụng này có thể sẽ đặt chuông báo trong hệ điều hành ứng dụng đánh thức thiết bị vào đầu phút để thời gian hiển thị có thể đã cập nhật. Ứng dụng không được thực hiện bất kỳ lệnh gọi API nào trong quá trình xử lý được liên kết với chuông báo đó.
Việc thực hiện lệnh gọi API để phản hồi một chuông báo đã khắc phục là việc không tốt vì việc này dẫn đến việc Lệnh gọi API được đồng bộ hoá với thời điểm bắt đầu phút, ngay cả giữa các lệnh gọi khác nhau thiết bị thay vì được phân phối đồng đều theo thời gian. Một ứng dụng có thiết kế kém khi ứng dụng thực hiện việc này, lưu lượng truy cập tăng đột biến ở mức bình thường 60 lần ở đầu mỗi phút.
Thay vào đó, bạn nên đặt chuông báo thứ hai thành thời gian đã chọn. Khi chuông báo thứ hai này kích hoạt, ứng dụng sẽ thực hiện lệnh gọi đến bất kỳ API mà hệ thống cần và lưu trữ kết quả. Để cập nhật màn hình hiển thị ở đầu phút, ứng dụng sẽ sử dụng các kết quả đã lưu trữ trước đó thay vì gọi hàm lại API. Với phương pháp này, các lệnh gọi API được trải đều theo thời gian. Hơn nữa, các lệnh gọi API không trì hoãn việc kết xuất khi màn hình đang được cập nhật.
Ngoài phút bắt đầu, các thời gian đồng bộ hoá phổ biến khác mà bạn phải cẩn thận để không nhắm mục tiêu đang ở đầu một giờ và đầu của mỗi ngày vào lúc nửa đêm.