روال‌های مطلوب

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

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

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

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

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

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

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

استفاده از پارامترهای اتصال در PQL

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

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

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

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

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

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

سهمیه API

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

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

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

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

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