Ủy quyền
Tất cả các yêu cầu đối với API Google Photos phải được người dùng đã xác thực cấp phép.
Các chi tiết của quy trình uỷ quyền cho OAuth 2.0 sẽ khác nhau đôi chút tuỳ thuộc vào loại ứng dụng 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:
- Hãy chuẩn bị cho quy trình uỷ quyền bằng cách làm như sau:
- Đăng ký ứng dụng bằng Google API Console.
- Kích hoạt API Photos và truy xuất thông tin chi tiết về OAuth, chẳng hạn như mã ứng dụng khách và khoá bí mật của ứ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 yêu cầu sự đồng ý cho người dùng để hỏi xem họ có cho phép ứng dụng yêu cầu một số dữ liệu của họ hay không.
- 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ã này là hợp lệ, Google sẽ trả về dữ liệu mà ứng dụng 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 cho một số loại ứng dụng có các bước bổ sung, chẳng hạn như sử dụng mã làm mới để 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 nghe nhìn và mã đĩa nhạc giúp nhận dạng riêng nội dung trong thư viện của người dùng sẽ được miễn trừ khỏi quy định 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ỳ thuộc vào chính sách quyền riêng tư của ứng dụng). 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. Để biết thêm thông tin, hãy xem phần Lấy một mục nội dung đa phương tiện hoặc Liệt kê đĩa nhạc.
Nếu bạn có nhiều mục nội dung nghe nhìn cần làm mới, bạn nên lưu trữ các tham số tìm kiếm đã trả về các mục nội dung nghe nhìn đó và gửi lại truy vấn để tải lại dữ liệu.
Quyền truy cập SSL
Tất cả các yêu cầu dịch vụ web của API Photos đều phải sử dụng giao thức HTTPS thông qua URL sau:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Các yêu cầu được thực hiện qua HTTP sẽ 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
Ứng dụng khách nên thử lại các lỗi 5xx bằng thời gian đợi luỹ thừa như mô tả trong phần 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 lỗi 429, ứng dụng có thể thử lại với độ trễ 30s tối thiểu. Đối với tất cả lỗi khác, bạn có thể không thử lại được. Đảm bảo yêu cầu của bạn là idempotent 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 yêu cầu. 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. Hành vi lặp lại này có thể làm quá tải mạng giữa ứng dụng của bạn và Google, đồng thời 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 cuộc 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 API của Google một cách lịch sự
Ứng dụng API được thiết kế không tốt có thể gây ra tải nhiều hơn mức cần thiết trên cả Internet và máy chủ của Google. Phần này trình bày một số phương pháp hay nhất cho ứng dụng của các 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ộ
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 điều này, bạn nên đảm bảo rằng các yêu cầu API không được đồng bộ hoá giữa các ứng dụng khách.
Ví dụ: hãy xem xét một ứng dụng hiển thị thời gian theo múi giờ hiện tại. Ứng dụng này có thể đặt chuông báo trong hệ điều hành của ứng dụng khách để đánh thức ứng dụng đó vào đầu phút để có thể cập nhật thời gian hiển thị. Ứ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 đó, một thiết kế hay có thể là đặt chuông báo thứ hai thành một thời gian được chọn ngẫu nhiê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 mọi API cần thiết và lưu trữ kết quả. Để cập nhật màn hình hiển thị vào đầu phút, ứng dụng sử dụng kết quả đã lưu trước đó thay vì gọi lại API. Với phương pháp này, các lệnh gọi API được phân bổ đều đặn theo thời gian. Ngoài ra, các lệnh gọi API không làm chậm quá trình kết xuất khi màn hình đang được cập nhật.
Ngoài thời điểm bắt đầu phút, bạn nên cẩn thận không nhắm đến các thời điểm đồng bộ hoá phổ biến khác như thời điểm bắt đầu giờ và thời điểm bắt đầu ngày vào lúc nửa đêm.