Ủy quyền
Tất cả các yêu cầu đến API Google Photos phải do người dùng đã xác thực thực hiện.
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 phần Bắt đầu.
- Để truy cập vào dữ liệu người dùng, ứng dụng sẽ gửi yêu cầu đến Google về một 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ẽ cấp cho ứng dụng một mã truy cập hết hạn sau một khoảng thời gian ngắn.
- Ứng dụng sẽ đưa ra yêu cầu về dữ liệu người dùng và đính kèm mã truy cập vào 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 những phạm vi phù hợp với ứng dụng của bạn, hãy xem phần Phạm vi uỷ quyền.
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 các loại ứng dụng khác nhau, hãy xem bài viết Sử dụng OAuth 2.0 để truy cập vào API của Google.
Lưu vào bộ nhớ đệm
Luôn cập nhật dữ liệu.
Nếu bạn cần tạm thời lưu trữ 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 nội dung đó vào bộ nhớ đệm lâu hơn 60 phút theo nguyên tắc sử dụng của chúng tôi.
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 mã nhận dạng mục nội dung nghe nhìn và mã nhận dạng đĩa nhạc để truy xuất lại URL và dữ liệu có thể truy cập bằ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ý lỗi được trả về từ API, hãy xem phần Xử lý lỗi của API đám mây.
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ừ phi 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 lỗi khi phân phát 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ể không thành công ở một vị trí nào đó giữa ứng dụng 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 tiếp theo 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 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.
Một phương pháp 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 theo hệ số nhân với mỗi lần thử, một phương pháp được gọi là Tạm ngưng theo cấp số nhân.
Bạn cũng nên cẩn thận để không có mã thử lại cao hơn trong chuỗi lệnh gọi ứng dụng dẫn đến các yêu cầu lặp lại liên tiếp.
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. Việc làm theo các phương pháp hay nhất này có thể giúp bạn tránh việc ứng dụng bị chặn do vô tình sử dụng sai API.
Yêu cầu đồng bộ
Một lượng lớn yêu cầu đồng bộ hoá đến các API của Google có thể trông giống như một cuộc tấn công từ chối dịch vụ phân tán (DDoS) vào cơ sở hạ tầng của Google và được xử lý tương ứng. Để 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ý liên quan đến chuông báo đó.
Việc thực hiện lệnh gọi API để phản hồi chuông báo cố định là không tốt vì điều này sẽ dẫn đến việc cá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 thiết bị khác nhau, thay vì được phân phối đều đặn theo thời gian. Một ứng dụng được thiết kế không tốt sẽ tạo ra lưu lượng truy cập tăng vọt gấp 60 lần mức bình thường vào đầ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 ở đầ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 là 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.