بهترین شیوه ها

این صفحه بهترین شیوه‌های مختلفی را پوشش می‌دهد که باید هنگام توسعه برنامه‌ها در برابر Google Ad Manager API در نظر گرفته شوند.

استفاده مجدد از سرویس گیرندگان/خردها در طول یک اجرا

ایجاد یک سرویس گیرنده/خرد جدید هزینه‌های نهایی مرتبط با واکشی WSDL و تخصیص منابع دارد. در صورت امکان، سرویس گیرنده/خرد را یک بار در ابتدای اجرا ایجاد کنید و در صورت نیاز آن را در اختیار کلاس ها و توابع قرار دهید.

هنگام واکشی اشیا از صفحه بندی استفاده کنید

همه سرویس ها از روش get*ByStatement() پشتیبانی می کنند که امکان فیلتر کردن نتایج را با استفاده از نحو PQL فراهم می کند. از بندهای LIMIT و OFFSET می توان برای تقسیم مجموعه های بزرگ نتایج به صفحات، جلوگیری از وقفه زمانی و معقول نگه داشتن اندازه صفحه پاسخ استفاده کرد. اندازه صفحه پیشنهادی 200-500 است، بسته به پیچیدگی اشیاء شما.

درخواست های به روز رسانی دسته ای

هنگام تغییر چندین شی از یک نوع، می توانید با ارسال همه اشیاء در یک درخواست update*() عملکرد بهتری داشته باشید. برای هر درخواست یک سربار حاشیه ای روی کلاینت و سرور وجود دارد و دسته بندی می تواند ابزار موثری برای کاهش تعداد درخواست ها باشد. برای مثال، ازupdateOrders برای به‌روزرسانی دسته‌ای از سفارش‌ها به جای یک سفارش در هر تماس استفاده کنید.

از پارامترهای bind در PQL استفاده کنید

پارامترهای Bind راهی برای قرار دادن متغیرها در یک عبارت کوئری PQL هستند. PQL به یک متغیر bind با نامی اشاره می کند که فاصله آن با دو نقطه شروع می شود، به عنوان مثال، :name . یک مثال کد در صفحه نحو PQL ارائه شده است.

ما استفاده از متغیرهای bind را توصیه می کنیم زیرا آنها خوانایی کد را با حذف نیاز به الحاق رشته ها و متغیرها در یک عبارت query بهبود می بخشند. آنها همچنین استفاده مجدد از عبارات PQL را آسان می کنند، زیرا پرس و جوهای جدید را می توان با جایگزین کردن مقادیر پارامتر bind ایجاد کرد.

امتیازات کاربر را در حد کم اعطا کنید

هنگام استفاده از UserService برای ایجاد/به‌روزرسانی نقش‌های کاربر، مراقب باشید به کاربرانی که به آن‌ها نیاز ندارند، امتیازی اعطا نکنید. بسیاری از ویژگی‌های API را می‌توان با ترکیبی از نقش‌ها به‌جای اختصاص دادن نقش مدیر به کاربر، دسترسی داشت. لطفاً هنگام تصمیم گیری در مورد اینکه کدام نقش ها را به کاربر اختصاص دهید، به اسناد مجوزها مراجعه کنید. همچنین، به عنوان یک توسعه‌دهنده برنامه شخص ثالث ، هنگام درخواست از شبکه برای ایجاد کاربر برای شما، مطمئن شوید که برنامه شما به چه سطح دسترسی نیاز دارد. نقشی با امتیازات کمتر از مدیر ممکن است کافی باشد.

در حد سهمیه بمانید

Ad Manager API چندین محدودیت سهمیه را برای استحکام اعمال می کند. مهم است که برنامه های خود را تحت این محدودیت ها نگه دارید و بدانید که چگونه به هر یک از خطاهای سهمیه ای که API می تواند برگرداند پاسخ دهید.

سهمیه API

اولین سهمیه اعمال شده برای درخواست های API یک سهمیه در سطح شبکه است. برای حساب‌های Ad Manager 360، محدودیت 8 درخواست در ثانیه و برای حساب‌های Ad Manager، 2 درخواست در ثانیه است. فراتر رفتن از این محدودیت منجر به خطای QuotaError.EXCEEDED_QUOTA می شود. تمام درخواست‌های API که در شبکه شما انجام می‌شود، برای این سهمیه اعمال می‌شود، از جمله برنامه‌های شخص ثالثی که شما یا شخصی در شرکتتان به آنها اجازه دسترسی به API را به شبکه شما داده است.

سهمیه های خاص سیستم

سهمیه API به تنهایی برای محافظت کافی از سیستم‌های خاص با منابع فشرده در Ad Manager کافی نیست. سیستم های گزارش و پیش بینی سهمیه های خود را تعیین می کنند که می تواند منجر به خطاهای API شود: QuotaError.REPORT_JOB_LIMIT و ForecastError.EXCEEDED_QUOTA به ترتیب.

رسیدگی به خطاهای سهمیه

اگر برنامه شما با هر یک از خطاهای سهمیه بالا مواجه شد، یک استراتژی برای امتحان مجدد درخواست API انجام دهید. توصیه می کنیم ابتدا حداقل 5 ثانیه منتظر بمانید، و اگر همچنان خطا را دریافت می کنید، از عقب نشینی نمایی برای افزایش زمان بین تلاش های مجدد استفاده کنید. اگر تلاش مجدد موفق نشد، برنامه های API خود را بررسی کنید تا ببینید آیا کاربرانی در شبکه شما سهمیه شما را خالی می کنند یا خیر.