Các phương pháp hay nhất

Trang này đề cập đến nhiều phương pháp hay nhất mà bạn nên cân nhắc khi phát triển ứng dụng dựa trên API Google Ad Manager.

Sử dụng lại các ứng dụng dịch vụ/mã giả lập trong quá trình thực thi

Việc tạo một ứng dụng khách/mã giả lập dịch vụ mới sẽ tốn ít chi phí biên liên quan đến việc tìm nạp WSDL và phân bổ tài nguyên. Nếu có thể, hãy tạo ứng dụng/mã giả lập dịch vụ một lần khi bắt đầu quá trình thực thi và cung cấp dịch vụ đó cho các lớp và hàm nếu cần.

Sử dụng chức năng phân trang khi tìm nạp đối tượng

Tất cả dịch vụ đều hỗ trợ phương thức get*ByStatement(), cho phép lọc kết quả bằng cú pháp PQL. Bạn có thể dùng mệnh đề LIMIT và OFFSET để phân tách các tập hợp kết quả lớn thành các trang, từ đó tránh hết thời gian chờ và duy trì kích thước trang phản hồi hợp lý. Kích thước trang đề xuất là 200-500, tuỳ thuộc vào độ phức tạp của các đối tượng.

Yêu cầu cập nhật theo lô

Khi thay đổi nhiều đối tượng cùng loại, bạn có thể đạt được hiệu suất tốt hơn bằng cách gửi tất cả đối tượng trong cùng một yêu cầu update*(). Máy khách và máy chủ có một mức hao tổn nhỏ đối với mỗi yêu cầu và việc phân lô có thể là một phương pháp hiệu quả để giảm số lượng yêu cầu. Ví dụ: sử dụng updateOrders để cập nhật một lô Đơn đặt hàng thay vì một đơn đặt hàng trong mỗi lệnh gọi.

Dùng các tham số liên kết trong PQL

Tham số liên kết là một cách để đưa các biến vào câu lệnh truy vấn PQL. PQL tham chiếu đến một biến liên kết theo tên không có dấu cách bắt đầu bằng dấu hai chấm, ví dụ: :name. Bạn có thể xem ví dụ về mã trên trang cú pháp PQL.

Bạn nên dùng các biến liên kết vì các biến này giúp cải thiện khả năng đọc mã bằng cách loại bỏ nhu cầu nối các chuỗi và biến vào một câu lệnh truy vấn. Các chú giải này cũng giúp bạn dễ dàng sử dụng lại các câu lệnh PQL, vì có thể thực hiện các truy vấn mới bằng cách thay thế các giá trị tham số liên kết.

Cấp đặc quyền của người dùng một cách thận trọng

Khi sử dụng UserService để tạo/cập nhật vai trò của người dùng, hãy cẩn thận để không cấp các đặc quyền mà họ không cần cho người dùng. Người dùng có thể truy cập nhiều tính năng của API bằng cách kết hợp các vai trò thay vì chỉ định vai trò quản trị viên cho người dùng. Vui lòng tham khảo tài liệu về quyền khi quyết định vai trò cần chỉ định cho người dùng. Ngoài ra, với tư cách là nhà phát triển ứng dụng bên thứ ba, hãy nhớ xác định cấp truy cập mà ứng dụng của bạn cần khi yêu cầu mạng tạo người dùng cho bạn; một vai trò có ít đặc quyền hơn quản trị viên có thể là đủ.

Không vượt quá hạn mức

API Ad Manager thực thi một số giới hạn về hạn mức cho độ mạnh mẽ. Điều quan trọng là duy trì ứng dụng trong các giới hạn này và bạn biết cách phản hồi bất kỳ lỗi nào về hạn mức mà API có thể trả về.

Hạn mức API

Hạn mức đầu tiên áp dụng cho các yêu cầu API là hạn mức cấp mạng. Đối với tài khoản Ad Manager 360, giới hạn là 8 yêu cầu mỗi giây và đối với tài khoản Ad Manager, giới hạn là 2 yêu cầu mỗi giây. Nếu vượt quá giới hạn này, bạn sẽ gặp lỗi QuotaError.EXCEEDED_QUOTA. Tất cả các yêu cầu API được thực hiện trên mạng của bạn đều áp dụng hạn mức này, bao gồm cả các ứng dụng bên thứ ba mà bạn hoặc ai đó trong công ty của bạn đã cấp quyền truy cập API vào mạng của bạn.

Hạn mức theo hệ thống cụ thể

Chỉ riêng hạn mức API là không đủ để bảo vệ đầy đủ một số hệ thống dùng nhiều tài nguyên trong Ad Manager. Các hệ thống báo cáo và dự báo xác định các hạn mức riêng có thể dẫn đến lỗi API: QuotaError.REPORT_JOB_LIMIT và ForecastError.EXCEEDED_QUOTA tương ứng.

Xử lý lỗi hạn mức

Nếu ứng dụng của bạn gặp bất kỳ lỗi nào trong số các lỗi hạn mức nêu trên, hãy thực hiện chiến lược để thử lại yêu cầu API. Trước tiên, bạn nên đợi ít nhất 5 giây. Nếu vẫn tiếp tục gặp lỗi, hãy sử dụng tính năng thời gian đợi luỹ thừa để tăng thời gian giữa các lần thử lại. Nếu thử lại không thành công, hãy kiểm tra các ứng dụng API để xem có người dùng nào trên mạng của bạn đang sử dụng hết hạn mức hay không.