Praktik Terbaik

Halaman ini membahas berbagai praktik terbaik yang harus dipertimbangkan saat mengembangkan aplikasi dengan Google Ad Manager API.

Menggunakan kembali klien/stub layanan selama menjalankan eksekusi

Pembuatan klien/stub layanan baru memerlukan biaya marginal yang terkait dengan pengambilan WSDL dan pengalokasian resource. Jika memungkinkan, buat klien/stub layanan satu kali pada awal eksekusi dan sediakan untuk class dan fungsi sesuai kebutuhan.

Menggunakan paging saat mengambil objek

Semua layanan mendukung metode get*ByStatement(), yang memungkinkan pemfilteran hasil menggunakan sintaksis PQL. Klausa LIMIT dan OFFSET dapat digunakan untuk membagi kumpulan hasil yang besar menjadi beberapa halaman, sehingga mencegah waktu tunggu dan menjaga ukuran halaman respons tetap wajar. Ukuran halaman yang disarankan adalah 200-500, bergantung pada kompleksitas objek Anda.

Permintaan update batch

Saat mengubah beberapa objek dari jenis yang sama, Anda bisa mendapatkan performa yang lebih baik dengan mengirim semua objek dalam permintaan update*() yang sama. Terdapat overhead marginal pada klien dan server untuk setiap permintaan, dan pengelompokan dapat menjadi cara yang efektif untuk mengurangi jumlah permintaan. Misalnya, gunakan updateOrders untuk memperbarui batch Pesanan, bukan satu urutan di setiap panggilan.

Menggunakan parameter binding di PQL

Parameter {i>Bind<i} adalah cara untuk memasukkan variabel ke dalam pernyataan kueri PQL. PQL mengacu pada variabel bind dengan nama tanpa spasi yang diawali dengan titik dua, misalnya, :name. Contoh kode diberikan di halaman sintaksis PQL.

Sebaiknya gunakan variabel binding karena akan meningkatkan keterbacaan kode dengan menghilangkan kebutuhan untuk menyambungkan string dan variabel ke dalam pernyataan kueri. Pernyataan PQL juga mempermudah penggunaan ulang pernyataan PQL, karena kueri baru dapat dibuat dengan mengganti nilai parameter bind.

Berikan hak istimewa pengguna seperlunya

Saat menggunakan UserService untuk membuat/memperbarui peran pengguna, berhati-hatilah untuk tidak memberikan hak istimewa yang tidak mereka perlukan. Banyak fitur API yang dapat diakses dengan kombinasi peran, bukan menetapkan peran administrator kepada pengguna. Harap baca dokumentasi izin saat menentukan peran yang akan ditetapkan kepada pengguna. Selain itu, sebagai developer aplikasi pihak ketiga, pastikan untuk menentukan tingkat akses yang diperlukan aplikasi saat meminta jaringan membuat pengguna untuk Anda; peran dengan hak istimewa yang lebih sedikit daripada administrator mungkin sudah cukup.

Tidak melebihi batas kuota

Ad Manager API menerapkan beberapa batas kuota untuk keandalan. Penting untuk menjaga aplikasi Anda tidak melebihi batas ini dan mengetahui cara merespons error kuota yang dapat ditampilkan API.

Kuota API

Kuota pertama yang diterapkan ke permintaan API adalah kuota tingkat jaringan. Untuk akun Ad Manager 360, batasnya adalah 8 permintaan per detik, dan untuk akun Ad Manager, batasnya adalah 2 permintaan per detik. Jika batas ini terlampaui, error QuotaError.EXCEEDED_QUOTA akan terjadi. Semua permintaan API yang dibuat pada jaringan Anda berlaku untuk kuota ini, termasuk aplikasi pihak ketiga yang telah diberi akses API ke jaringan Anda oleh Anda atau seseorang di perusahaan Anda.

Kuota khusus sistem

Kuota API saja tidak cukup untuk melindungi sistem yang menggunakan banyak resource tertentu secara memadai dalam Ad Manager. Sistem pelaporan dan perkiraan menentukan kuotanya sendiri yang dapat mengakibatkan error API: QuotaError.REPORT_JOB_LIMIT dan ForecastError.EXCEEDED_QUOTA.

Menangani error kuota

Jika aplikasi Anda mengalami salah satu error kuota di atas, jalankan strategi untuk mencoba kembali permintaan API. Sebaiknya tunggu minimal 5 detik terlebih dahulu, dan jika Anda terus mengalami error, gunakan backoff eksponensial untuk memperpanjang waktu antar-percobaan ulang. Jika percobaan ulang tidak berhasil, lakukan audit pada aplikasi API Anda untuk melihat apakah ada pengguna di jaringan Anda yang menghabiskan kuota.