محدودیت‌ها و سهمیه‌ها از زیرساخت Google در برابر فرآیند خودکاری که از API انتقال داده به روشی نامناسب استفاده می‌کند محافظت می‌کند. درخواست‌های بیش از حد از یک API ممکن است ناشی از یک اشتباه تایپی بی‌ضرر باشد، یا ممکن است ناشی از طراحی ناکارآمد سیستمی باشد که تماس‌های API بی‌ضروری را ایجاد می‌کند. صرف نظر از علت، مسدود کردن ترافیک از یک منبع خاص زمانی که به سطح معینی می رسد برای سلامت کلی سیستم Google Workspace ضروری است. این تضمین می کند که اقدامات یک توسعه دهنده نمی تواند تأثیر منفی بر جامعه بزرگتر بگذارد.
شکست درخواست API
در صورتی که درخواست API شما ناموفق باشد، برنامه شما پاسخ کد وضعیت HTTP را دریافت می کند. کد وضعیت 403 دارای اطلاعات خطا در مورد ورودی نادرست است و کد وضعیت HTTP 503 دارای اطلاعات خطایی است که نشان می دهد از سهمیه های API فراتر رفته است. این پاسخ‌ها به برنامه سفارشی شما اجازه می‌دهد این خطاها را شناسایی کرده و اقدامات لازم را انجام دهد.
درخواست ها را در یک بازه زمانی مشخص تکمیل کنید
اگر درخواست‌های شما باید در یک بازه زمانی مشخص تکمیل شوند، درخواست‌های خود را به صورت موازی ارسال کنید یا از چندین رشته در برنامه جاوا یا سی شارپ خود استفاده کنید. به عنوان مثال، درخواست های خود را بر اساس ماه یا دوره زمانی دیگر بشکنید. در مورد رشته ها، سعی کنید با 10 رشته شروع کنید، هر درخواست یک رشته. توصیه رشته دارای معاوضه هایی است و برای همه موقعیت های API مفید نیست. اگر تعداد درخواست ها خیلی زیاد شود، خطاهای سهمیه ای رخ می دهد.
خطاهای مبتنی بر زمان
برای همه خطاهایی که مبتنی بر زمان هستند (حداکثر N چیز برای X ثانیه در هر رشته)، به خصوص خطاهای کد وضعیت 503 ، توصیه می کنیم کد شما استثنا را بگیرد و با استفاده از یک الگوریتم عقب نشینی نمایی ، قبل از امتحان مجدد، کمی تاخیر صبر کنید. تماس ناموفق یک مثال API انتقال داده برای یک رشته این است که 5 ثانیه صبر کنید و تماس ناموفق را دوباره امتحان کنید. اگر درخواست موفقیت آمیز بود، این الگو را برای رشته های دیگر تکرار کنید. اگر درخواست دوم موفقیت آمیز نبود، برنامه شما باید تعداد دفعات درخواست را کاهش دهد تا زمانی که تماس موفقیت آمیز باشد. به عنوان مثال، 5 ثانیه تاخیر اولیه را به 10 ثانیه افزایش دهید و دوباره تماس ناموفق خود را دوباره امتحان کنید. همچنین، در مورد محدودیت تلاش مجدد تصمیم بگیرید. به عنوان مثال، قبل از اینکه برنامه شما خطایی را به کاربر بازگرداند، یک درخواست را 5 تا 7 بار با زمان‌های تاخیر متفاوت امتحان کنید.
محدودیت ها
| دسته های محدودیت API | محدودیت ها |
|---|---|
| پرس و جو در ثانیه (QPS) | محدودیت پروژه توسعه دهنده 10 پرس و جو در ثانیه (QPS) در هر حساب است. |
سهمیه ها
| دسته های سهمیه API | سهمیه ها |
|---|---|
| حداکثر درخواست API در روز | حداکثر درخواست API در روز 500000 است. |
| آرشیو، انقضای پیام ها | بایگانی گروه منقضی نمی شود. تا زمانی که گروه حذف نشود، پیام‌ها در بایگانی باقی می‌مانند. خط‌مشی حفظ ایمیل بر پیام‌های موجود در بایگانی گروه تأثیری نمی‌گذارد. |
| اندازه پیام ایمیل | حداکثر اندازه پیام نامه 25 مگابایت است. این محدودیت شامل سرصفحه‌های متا داده پیام، متن و هر پیوستی می‌شود. |
انواع دیگر محدودیت ها
| انواع دیگر محدودیت ها | محدودیت ها و دستورالعمل ها |
|---|---|
| فرمت های نوع محتوا | یک پیام ایمیل باید در قالب متن استاندارد RFC 822 باشد. فرمت نوع محتوای درخواست برای آپلود ایمیل‌های انتقال‌یافته از هدر Content-type: message/rfc822 استفاده می‌کند. |
| قالب داده در پاسخ های API | فرمت داده پاسخ عبارت است از Javascript Object Notation ( JSON ). |
| خط مشی های مکان داده | Data Transfer API از خط‌مشی‌های مکان داده پشتیبانی نمی‌کند که به دلایل قراردادی باید داده‌ها در مرزهای جغرافیایی یا سیاسی خاص ذخیره شوند. اگر مکان داده برای حساب شما لازم است از Data Transfer API استفاده نکنید. |
| درج پیام موازی | Data Transfer API از درخواست های موازی برای درج ایمیل در آرشیوهای گروهی مختلف پشتیبانی می کند. اما Data Transfer API از درج پیام موازی در همان آرشیو گروه پشتیبانی نمی کند. همچنین درخواست های دسته ای در این نسخه از API پشتیبانی نمی شوند. |
| درخواست های غیرمجاز | Data Transfer API هیچ درخواست غیرمجاز را نمی پذیرد. در صورت عدم ارائه کد مجوز، درخواست غیرمجاز تلقی می شود. |