Giới hạn và hạn mức giúp bảo vệ cơ sở hạ tầng của Google khỏi một quy trình tự động sử dụng Reports API theo cách không phù hợp. Việc gửi quá nhiều yêu cầu từ một API có thể là do lỗi chính tả vô hại hoặc do một hệ thống được thiết kế không hiệu quả, khiến hệ thống thực hiện các lệnh gọi API không cần thiết. Bất kể nguyên nhân là gì, việc chặn lưu lượng truy cập từ một nguồn cụ thể khi lưu lượng truy cập đó đạt đến một mức nhất định là cần thiết để đảm bảo tình trạng tổng thể của hệ thống Google Workspace. Việc này đảm bảo rằng hành động của một nhà phát triển không thể gây ảnh hưởng tiêu cực đến cộng đồng lớn hơn.
Trong trường hợp không mong muốn là yêu cầu API của bạn không thành công, bạn sẽ nhận được một phản hồi về mã trạng thái HTTP. Mã trạng thái 403 có thông tin lỗi về dữ liệu đầu vào không chính xác và mã trạng thái HTTP 503 có thông tin lỗi cho biết những hạn mức API nào đã bị vượt quá. Những phản hồi này cho phép ứng dụng tuỳ chỉnh của bạn phát hiện các lỗi này và thực hiện hành động thích hợp.
Nếu yêu cầu của bạn cần được hoàn tất trong một khoảng thời gian cố định, hãy gửi các yêu cầu đó song song hoặc sử dụng nhiều luồng trong ứng dụng Java hoặc C#. Ví dụ về các yêu cầu song song là yêu cầu các lô email nhỏ từ nhiều người dùng thay vì thêm hoặc xoá nhiều email của một người dùng cùng lúc. Trong trường hợp có các luồng, hãy thử bắt đầu với 10 luồng, mỗi luồng một email của người dùng. Xin lưu ý rằng đề xuất về luồng có những điểm đánh đổi và không hữu ích cho mọi trường hợp sử dụng API. Nếu số lượng yêu cầu quá cao, lỗi hạn mức sẽ xảy ra.
Đối với tất cả các lỗi dựa trên thời gian (tối đa N mục trong N giây cho mỗi luồng), đặc biệt là các lỗi mã trạng thái 503, bạn nên để mã của mình bắt ngoại lệ và sử dụng thuật toán thời gian chờ theo cấp số nhân , đợi một khoảng thời gian ngắn trước khi thử lại lệnh gọi không thành công. Ví dụ về Reports API cho một luồng là đợi 5 giây và thử lại lệnh gọi không thành công. Nếu yêu cầu thành công, hãy lặp lại mẫu này cho các luồng khác. Nếu yêu cầu thứ hai không thành công, ứng dụng của bạn nên giảm tần suất của yêu cầu cho đến khi một lệnh gọi thành công. Ví dụ: tăng thời gian chờ ban đầu từ 5 giây lên 10 giây và thử lại lệnh gọi không thành công. Ngoài ra, hãy quyết định giới hạn số lần thử lại. Ví dụ: thử lại một yêu cầu từ 5 đến 7 lần với các khoảng thời gian chờ khác nhau trước khi ứng dụng của bạn trả về lỗi cho người dùng.
Giới hạn
| Danh mục giới hạn API | Giới hạn |
|---|---|
| Tỷ lệ QPS và QPD của báo cáo | API này giới hạn số lượng yêu cầu cho dự án Google Cloud của bạn.
Giá trị mặc định được đặt trong bảng điều khiển Google Cloud là 2.400 truy vấn mỗi phút
cho mỗi người dùng cho mỗi dự án Google Cloud. Bạn có thể tăng giới hạn này trên
trang Hạn mức API của SDK dành cho quản trị viên
trong dự án Google Cloud.
Nếu các giới hạn này bị vượt quá, máy chủ sẽ trả về mã trạng thái HTTP 503 mã. Hãy sử dụng thuật toán thời gian chờ theo cấp số nhân khi thử lại các yêu cầu. |
Các giới hạn khác cho activities.list |
API activities.list có thêm giới hạn là 250
truy vấn bộ lọc mỗi phút (15.000 truy vấn bộ lọc mỗi giờ). Truy vấn bộ lọc
là một yêu cầu API chứa ít nhất một trong các tham số truy vấn
sau:
|
| Danh mục hạn mức API | Hạn mức |
| maxResults | Số lượng bản ghi được liệt kê trong mỗi trang của phản hồi API là từ 0 đến 1000 bản ghi. Giá trị mặc định là 1000 bản ghi. |
Các loại giới hạn khác
| Các loại giới hạn khác | Giới hạn và nguyên tắc |
|---|---|
| Định dạng dữ liệu, mặc định | Định dạng dữ liệu mặc định là JSON. API này cũng hỗ trợ định dạng Atom. |
| Yêu cầu không được uỷ quyền | Google không cho phép các yêu cầu không được uỷ quyền gửi đến API. Một yêu cầu được coi là không được uỷ quyền nếu không có mã thông báo uỷ quyền nào được cung cấp. Để biết thêm thông tin, hãy xem Uỷ quyền cho các yêu cầu. |
| Thông báo cảnh báo |
|
Các phương pháp hay nhất cho activities.list
Phương thức
activities.list
dự kiến sẽ được dùng cho các cuộc điều tra kiểm toán. Để có hiệu suất tốt nhất, yêu cầu của bạn phải bao gồm một phạm vi thời gian bằng cách sử dụng các
startTime và endTime tham số. Phạm vi thời gian hẹp hơn
sẽ giúp thời gian phản hồi nhanh hơn đáng kể. Phương thức này không dành cho việc truy xuất nhật ký kiểm toán với số lượng lớn. Nếu bạn thường xuyên
sử dụng hết hạn mức yêu cầu bộ lọc activities.list, hãy cân nhắc các lựa chọn
sau:
- Thiết lập tính năng xuất nhật ký Google Workspace sang BigQuery và sử dụng các API truy vấn mạnh mẽ của BigQuery để truy xuất và phân tích dữ liệu bạn cần mà không có bất kỳ hạn chế nào về hạn mức API.
- Sử dụng các yêu cầu không có bộ lọc với phạm vi thời gian và thực hiện việc lọc ở phía máy khách (tức là thực hiện logic lọc trong ứng dụng của bạn), thay vì sử dụng các yêu cầu có bộ lọc. Việc này cho phép bạn vượt qua giới hạn 250 truy vấn bộ lọc mỗi phút nhưng bạn vẫn phải tuân theo giới hạn 2.400 truy vấn mỗi phút cho mỗi người dùng cho mỗi dự án Google Cloud.