Ủy quyền
Tất cả các yêu cầu gửi tới API thư viện Google Photos phải được một người dùng đã xác thực cấp phép.
Thông tin chi tiết về quy trình uỷ quyền cho OAuth 2.0 có thể khác nhau đôi chút tuỳ thuộc vào 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 uỷ quyền bằng cách làm như sau:
- Đăng ký ứng dụng của bạn bằng Google API Console.
- Kích hoạt API thư viện và truy xuất thông tin chi tiết về OAuth 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ài viết 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 tới Google về một phạm vi truy cập cụ thể.
- Google hiển thị màn hình xin phép cho người dùng để yêu cầu họ cho phép ứng dụng yêu cầu một số dữ liệu của họ.
- Nếu người dùng phê duyệt, 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 gửi yêu cầu về dữ liệu người dùng, đí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ã 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 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 bao gồm 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 bài viết Sử dụng OAuth 2.0 để truy cập API của Google.
Chức năng 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 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, 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 nhận dạng riêng nội dung trong thư viện của người dùng sẽ đượ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ư của ứng dụng). Sử dụng mã mục nội dung đa phương tiện và mã album để truy xuất lại dữ liệu và URL 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 Tải mục nội dung nghe nhìn hoặc Liệt kê album.
Nếu cần làm mới nhiều mục nội dung đa phương tiện, bạn nên lưu trữ các 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 dữ liệu.
Truy cập SSL
HTTPS là bắt buộc đối với tất cả các yêu cầu dịch vụ web API Thư viện thông qua URL sau:
https://photoslibrary.googleapis.com/v1/service/output?parameters
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 trả về từ API, hãy xem phần Xử lý lỗi của API Cloud.
Đang thử lại các yêu cầu không thành công
Ứng dụng nên thử lại các lỗi 5xx bằng thuật toán 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 chú khác.
Đối với 429 lỗi, máy khách có thể thử lại với độ trễ tối thiểu là 30s. Đối với tất cả các lỗi khác, có thể tính năng thử lại không áp dụng được. Hãy đảm bảo yêu cầu của bạn không có hiệu lực 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, đã 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 có thể kết nối TCP 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 tiếp theo có thể thành công trong 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, gửi yêu cầu liên tục đến các 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, từ đó gây ra sự cố cho nhiều bên.
Một phương pháp hiệu quả hơn là thử lại và tăng độ trễ giữa các lần thử. Thông thường, độ trễ sẽ được tăng lên theo hệ số nhân với mỗi lần thử, phương pháp này được gọi là Thời gian đợi luỹ thừa.
Bạn cũng nên cẩn thận để không có thử lại mã 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ự
Các ứng dụng API được thiết kế kém 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 dành cho ứng dụng 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 được việc ứng dụng bị chặn do vô tình sử dụng API.
Yêu cầu đã đồng bộ hoá
Số lượng lớn các yêu cầu được đồng bộ hoá tới API của Google có thể giống như một cuộc 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ần được xử lý phù hợp. Để tránh điều này, bạn phải đả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.
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ể sẽ đặt chuông báo trong hệ điều hành ứng dụng đánh thức nó 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 một chuông báo cố định là không tốt vì điều này dẫn đến việc các lệnh gọi API được đồng bộ hoá với đầu phút, ngay cả giữa các thiết bị khác nhau, thay vì được phân phối đồng đều theo thời gian. Một ứng dụng được thiết kế không tốt khi thực hiện việc này sẽ tạo ra mức tăng đột biến về lưu lượng truy cập ở mức 60 lần mức bình thường vào đầu mỗi phút.
Thay vào đó, bạn nên đặt chuông báo thứ hai theo 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 bất kỳ API nào mà ứng dụng cần và lưu trữ kết quả. Để cập nhật màn hình vào đầu phút, ứng dụng sẽ sử dụng các kết quả đã lưu trữ 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 trải đều theo thời gian. Ngoài ra, 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 thời gian bắt đầu một phút, các thời gian đồng bộ hoá phổ biến khác mà bạn nên cẩn thận để không nhắm mục tiêu là ở đầu một giờ và bắt đầu mỗi ngày vào lúc nửa đêm.