پاسخ به خطا، پاسخ به خطا، پاسخ به خطا

پاسخ های خطای استاندارد

اگر یک درخواست Reporting API موفقیت آمیز باشد، API 200 برمی گرداند. اگر در یک درخواست خطایی رخ دهد، API کد وضعیت HTTP، وضعیت و دلیل را بر اساس نوع خطا در پاسخ برمی‌گرداند. علاوه بر این، بدنه پاسخ حاوی شرح مفصلی از آنچه باعث خطا شده است. در اینجا نمونه ای از پاسخ به خطا آورده شده است:

{
 "error": {
  "code": 403,
  "message": "User does not have sufficient permissions for this profile.",
  "status": "PERMISSION_DENIED"
 }
}

جدول خطا

کد وضعیت شرح عمل پیشنهاد شده
400 INVALID_ARGUMENT درخواست نامعتبر است. ممکن است یک آرگومان مورد نیاز وجود نداشته باشد، از حد مجاز فراتر رفته یا مقدار نامعتبری داشته باشد. برای جزئیات، پیام خطا را بررسی کنید. اگر مشتری مجدداً آن را تکرار کند، این خطا دوباره با شکست مواجه می شود.
401 UNAUTHENTICATED مشتری به درستی احراز هویت نشده است. بدون رفع مشکل دوباره امتحان نکنید. شما باید یک نشانه تأیید جدید دریافت کنید.
403 PERMISSION_DENIED نشان دهنده درخواست داده هایی است که کاربر به آنها دسترسی ندارد. بدون رفع مشکل دوباره امتحان نکنید. برای انجام عملیات روی موجودیت مشخص شده باید مجوزهای کافی دریافت کنید.
429 RESOURCE_EXHAUSTED Analytics DefaultGroupCLIENT_PROJECT-1d نشان می دهد که درخواست های روزانه به ازای هر سهمیه پروژه تمام شده است. بدون رفع مشکل دوباره امتحان نکنید. سهمیه روزانه خود را تمام کرده اید.
429 RESOURCE_EXHAUSTED Analytics DefaultGroupCLIENT_PROJECT-100s نشان می دهد که درخواست ها در هر 100 ثانیه برای هر سهمیه پروژه تمام شده است. با استفاده از عقب نشینی نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
429 RESOURCE_EXHAUSTED AnalyticsDefaultGroupUSER-100s نشان می دهد که درخواست ها در هر 100 ثانیه برای هر کاربر در هر سهمیه پروژه تمام شده است. با استفاده از عقب نشینی نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
429 RESOURCE_EXHAUSTED DiscoveryGroupCLIENT_PROJECT-100s نشان می دهد که درخواست های کشف در هر سهمیه 100 ثانیه تمام شده است. پاسخ کشف اغلب تغییر نمی کند. پاسخ کشف را به صورت محلی ذخیره کنید یا با استفاده از پشتوانه نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
500 INTERNAL خطای سرور داخلی غیرمنتظره رخ داد. این پرس و جو را بیش از یک بار تکرار نکنید.
503 BACKEND_ERROR سرور یک خطا برگرداند. این پرس و جو را بیش از یک بار تکرار نکنید.
503 UNAVAILABLE سرویس نتوانست درخواست را پردازش کند. این به احتمال زیاد یک وضعیت گذرا است و ممکن است با تلاش مجدد با عقب نشینی نمایی اصلاح شود.

پیاده سازی عقب نشینی نمایی

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

جریان برای اجرای پس‌انداز نمایی ساده به شرح زیر است.

  1. یک درخواست به API بدهید
  2. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  3. 1 ثانیه + random_number_milliseconds ثانیه صبر کنید
  4. درخواست مجدد
  5. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  6. 2 ثانیه + random_number_milliseconds ثانیه صبر کنید
  7. درخواست مجدد
  8. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  9. 4 ثانیه + random_number_milliseconds ثانیه صبر کنید
  10. درخواست مجدد
  11. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  12. 8 ثانیه + random_number_milliseconds ثانیه صبر کنید
  13. درخواست مجدد
  14. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  15. 16 ثانیه + random_number_milliseconds ثانیه صبر کنید
  16. درخواست مجدد
  17. اگر باز هم با خطا مواجه شدید، توقف کرده و خطا را ثبت کنید.

در جریان فوق، random_number_milliseconds تعداد تصادفی میلی ثانیه کمتر یا مساوی 1000 است. این برای جلوگیری از خطاهای قفل خاص در برخی از پیاده سازی های همزمان ضروری است. random_number_milliseconds باید بعد از هر انتظار دوباره تعریف شود.

توجه : انتظار همیشه (2 ^ n) + random_number_milliseconds است، که در آن n یک عدد صحیح افزایشی یکنواخت است که در ابتدا 0 تعریف شده است. n برای هر تکرار (هر درخواست) 1 افزایش می یابد.

الگوریتم تنظیم شده است تا زمانی که n 5 باشد خاتمه یابد. این سقف فقط برای جلوگیری از تلاش مجدد مشتریان برای بی نهایت وجود دارد و منجر به تأخیر کلی حدود 32 ثانیه قبل از تلقی درخواست "خطای غیرقابل جبران" می شود.

کد پایتون زیر پیاده سازی جریان فوق برای بازیابی خطاهایی است که در روشی به نام makeRequest رخ می دهد.

import random
import time
from apiclient.errors import HttpError

def makeRequestWithExponentialBackoff(analytics):
  """Wrapper to request Google Analytics data with exponential backoff.

  The makeRequest method accepts the analytics service object, makes API
  requests and returns the response. If any error occurs, the makeRequest
  method is retried using exponential backoff.

  Args:
    analytics: The analytics service object

  Returns:
    The API response from the makeRequest method.
  """
  for n in range(0, 5):
    try:
      return makeRequest(analytics)

    except HttpError, error:
      if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
                               'internalServerError', 'backendError']:
        time.sleep((2 ** n) + random.random())
      else:
        break

  print "There has been an error, the request never succeeded."
،

پاسخ های خطای استاندارد

اگر یک درخواست Reporting API موفقیت آمیز باشد، API 200 برمی گرداند. اگر در یک درخواست خطایی رخ دهد، API کد وضعیت HTTP، وضعیت و دلیل را بر اساس نوع خطا در پاسخ برمی‌گرداند. علاوه بر این، بدنه پاسخ حاوی شرح مفصلی از آنچه باعث خطا شده است. در اینجا نمونه ای از پاسخ به خطا آورده شده است:

{
 "error": {
  "code": 403,
  "message": "User does not have sufficient permissions for this profile.",
  "status": "PERMISSION_DENIED"
 }
}

جدول خطا

کد وضعیت شرح عمل پیشنهاد شده
400 INVALID_ARGUMENT درخواست نامعتبر است. ممکن است یک آرگومان مورد نیاز وجود نداشته باشد، از حد مجاز فراتر رفته یا مقدار نامعتبری داشته باشد. برای جزئیات، پیام خطا را بررسی کنید. اگر مشتری مجدداً آن را تکرار کند، این خطا دوباره با شکست مواجه می شود.
401 UNAUTHENTICATED مشتری به درستی احراز هویت نشده است. بدون رفع مشکل دوباره امتحان نکنید. شما باید یک نشانه تأیید جدید دریافت کنید.
403 PERMISSION_DENIED نشان دهنده درخواست داده هایی است که کاربر به آنها دسترسی ندارد. بدون رفع مشکل دوباره امتحان نکنید. برای انجام عملیات روی موجودیت مشخص شده باید مجوزهای کافی دریافت کنید.
429 RESOURCE_EXHAUSTED Analytics DefaultGroupCLIENT_PROJECT-1d نشان می دهد که درخواست های روزانه به ازای هر سهمیه پروژه تمام شده است. بدون رفع مشکل دوباره امتحان نکنید. سهمیه روزانه خود را تمام کرده اید.
429 RESOURCE_EXHAUSTED Analytics DefaultGroupCLIENT_PROJECT-100s نشان می دهد که درخواست ها در هر 100 ثانیه برای هر سهمیه پروژه تمام شده است. با استفاده از عقب نشینی نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
429 RESOURCE_EXHAUSTED AnalyticsDefaultGroupUSER-100s نشان می دهد که درخواست ها در هر 100 ثانیه برای هر کاربر در هر سهمیه پروژه تمام شده است. با استفاده از عقب نشینی نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
429 RESOURCE_EXHAUSTED DiscoveryGroupCLIENT_PROJECT-100s نشان می دهد که درخواست های کشف در هر سهمیه 100 ثانیه تمام شده است. پاسخ کشف اغلب تغییر نمی کند. پاسخ کشف را به صورت محلی ذخیره کنید یا با استفاده از پشتوانه نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
500 INTERNAL خطای سرور داخلی غیرمنتظره رخ داد. این پرس و جو را بیش از یک بار تکرار نکنید.
503 BACKEND_ERROR سرور یک خطا برگرداند. این پرس و جو را بیش از یک بار تکرار نکنید.
503 UNAVAILABLE سرویس نتوانست درخواست را پردازش کند. این به احتمال زیاد یک وضعیت گذرا است و ممکن است با تلاش مجدد با عقب نشینی نمایی اصلاح شود.

پیاده سازی عقب نشینی نمایی

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

جریان برای اجرای پس‌انداز نمایی ساده به شرح زیر است.

  1. یک درخواست به API بدهید
  2. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  3. 1 ثانیه + random_number_milliseconds ثانیه صبر کنید
  4. درخواست مجدد
  5. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  6. 2 ثانیه + random_number_milliseconds ثانیه صبر کنید
  7. درخواست مجدد
  8. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  9. 4 ثانیه + random_number_milliseconds ثانیه صبر کنید
  10. درخواست مجدد
  11. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  12. 8 ثانیه + random_number_milliseconds ثانیه صبر کنید
  13. درخواست مجدد
  14. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  15. 16 ثانیه + random_number_milliseconds ثانیه صبر کنید
  16. درخواست مجدد
  17. اگر باز هم با خطا مواجه شدید، توقف کرده و خطا را ثبت کنید.

در جریان فوق، random_number_milliseconds تعداد تصادفی میلی ثانیه کمتر یا مساوی 1000 است. این برای جلوگیری از خطاهای قفل خاص در برخی از پیاده سازی های همزمان ضروری است. random_number_milliseconds باید بعد از هر انتظار دوباره تعریف شود.

توجه : انتظار همیشه (2 ^ n) + random_number_milliseconds است، که در آن n یک عدد صحیح افزایشی یکنواخت است که در ابتدا 0 تعریف شده است. n برای هر تکرار (هر درخواست) 1 افزایش می یابد.

الگوریتم تنظیم شده است تا زمانی که n 5 باشد خاتمه یابد. این سقف فقط برای جلوگیری از تلاش مجدد مشتریان برای بی نهایت وجود دارد و منجر به تأخیر کلی حدود 32 ثانیه قبل از تلقی درخواست "خطای غیرقابل جبران" می شود.

کد پایتون زیر پیاده سازی جریان فوق برای بازیابی خطاهایی است که در روشی به نام makeRequest رخ می دهد.

import random
import time
from apiclient.errors import HttpError

def makeRequestWithExponentialBackoff(analytics):
  """Wrapper to request Google Analytics data with exponential backoff.

  The makeRequest method accepts the analytics service object, makes API
  requests and returns the response. If any error occurs, the makeRequest
  method is retried using exponential backoff.

  Args:
    analytics: The analytics service object

  Returns:
    The API response from the makeRequest method.
  """
  for n in range(0, 5):
    try:
      return makeRequest(analytics)

    except HttpError, error:
      if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
                               'internalServerError', 'backendError']:
        time.sleep((2 ** n) + random.random())
      else:
        break

  print "There has been an error, the request never succeeded."
،

پاسخ های خطای استاندارد

اگر یک درخواست Reporting API موفقیت آمیز باشد، API 200 برمی گرداند. اگر در یک درخواست خطایی رخ دهد، API کد وضعیت HTTP، وضعیت و دلیل را بر اساس نوع خطا در پاسخ برمی‌گرداند. علاوه بر این، بدنه پاسخ حاوی شرح مفصلی از آنچه باعث خطا شده است. در اینجا نمونه ای از پاسخ به خطا آورده شده است:

{
 "error": {
  "code": 403,
  "message": "User does not have sufficient permissions for this profile.",
  "status": "PERMISSION_DENIED"
 }
}

جدول خطا

کد وضعیت شرح عمل پیشنهاد شده
400 INVALID_ARGUMENT درخواست نامعتبر است. ممکن است یک آرگومان مورد نیاز وجود نداشته باشد، از حد مجاز فراتر رفته یا مقدار نامعتبری داشته باشد. برای جزئیات، پیام خطا را بررسی کنید. اگر مشتری مجدداً آن را تکرار کند، این خطا دوباره با شکست مواجه می شود.
401 UNAUTHENTICATED مشتری به درستی احراز هویت نشده است. بدون رفع مشکل دوباره امتحان نکنید. شما باید یک نشانه تأیید جدید دریافت کنید.
403 PERMISSION_DENIED نشان دهنده درخواست داده هایی است که کاربر به آنها دسترسی ندارد. بدون رفع مشکل دوباره امتحان نکنید. برای انجام عملیات روی موجودیت مشخص شده باید مجوزهای کافی دریافت کنید.
429 RESOURCE_EXHAUSTED Analytics DefaultGroupCLIENT_PROJECT-1d نشان می دهد که درخواست های روزانه به ازای هر سهمیه پروژه تمام شده است. بدون رفع مشکل دوباره امتحان نکنید. سهمیه روزانه خود را تمام کرده اید.
429 RESOURCE_EXHAUSTED Analytics DefaultGroupCLIENT_PROJECT-100s نشان می دهد که درخواست ها در هر 100 ثانیه برای هر سهمیه پروژه تمام شده است. با استفاده از عقب نشینی نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
429 RESOURCE_EXHAUSTED AnalyticsDefaultGroupUSER-100s نشان می دهد که درخواست ها در هر 100 ثانیه برای هر کاربر در هر سهمیه پروژه تمام شده است. با استفاده از عقب نشینی نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
429 RESOURCE_EXHAUSTED DiscoveryGroupCLIENT_PROJECT-100s نشان می دهد که درخواست های کشف در هر سهمیه 100 ثانیه تمام شده است. پاسخ کشف اغلب تغییر نمی کند. پاسخ کشف را به صورت محلی ذخیره کنید یا با استفاده از پشتوانه نمایی دوباره امتحان کنید. باید سرعت ارسال درخواست ها را کاهش دهید.
500 INTERNAL خطای سرور داخلی غیرمنتظره رخ داد. این پرس و جو را بیش از یک بار تکرار نکنید.
503 BACKEND_ERROR سرور یک خطا برگرداند. این پرس و جو را بیش از یک بار تکرار نکنید.
503 UNAVAILABLE سرویس نتوانست درخواست را پردازش کند. این به احتمال زیاد یک وضعیت گذرا است و ممکن است با تلاش مجدد با عقب نشینی نمایی اصلاح شود.

پیاده سازی عقب نشینی نمایی

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

جریان برای اجرای پس‌انداز نمایی ساده به شرح زیر است.

  1. یک درخواست به API بدهید
  2. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  3. 1 ثانیه + random_number_milliseconds ثانیه صبر کنید
  4. درخواست مجدد
  5. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  6. 2 ثانیه + random_number_milliseconds ثانیه صبر کنید
  7. درخواست مجدد
  8. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  9. 4 ثانیه + random_number_milliseconds ثانیه صبر کنید
  10. درخواست مجدد
  11. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  12. 8 ثانیه + random_number_milliseconds ثانیه صبر کنید
  13. درخواست مجدد
  14. پاسخ خطایی را دریافت کنید که دارای کد خطای قابل امتحان مجدد است
  15. 16 ثانیه + random_number_milliseconds ثانیه صبر کنید
  16. درخواست مجدد
  17. اگر باز هم با خطا مواجه شدید، توقف کرده و خطا را ثبت کنید.

در جریان فوق، random_number_milliseconds تعداد تصادفی میلی ثانیه کمتر یا مساوی 1000 است. این برای جلوگیری از خطاهای قفل خاص در برخی از پیاده سازی های همزمان ضروری است. random_number_milliseconds باید بعد از هر انتظار دوباره تعریف شود.

توجه : انتظار همیشه (2 ^ n) + random_number_milliseconds است، که در آن n یک عدد صحیح افزایشی یکنواخت است که در ابتدا 0 تعریف شده است. n برای هر تکرار (هر درخواست) 1 افزایش می یابد.

الگوریتم تنظیم شده است تا زمانی که n 5 باشد خاتمه یابد. این سقف فقط برای جلوگیری از تلاش مجدد مشتریان برای بی نهایت وجود دارد و منجر به تأخیر کلی حدود 32 ثانیه قبل از تلقی درخواست "خطای غیرقابل جبران" می شود.

کد پایتون زیر پیاده سازی جریان فوق برای بازیابی خطاهایی است که در روشی به نام makeRequest رخ می دهد.

import random
import time
from apiclient.errors import HttpError

def makeRequestWithExponentialBackoff(analytics):
  """Wrapper to request Google Analytics data with exponential backoff.

  The makeRequest method accepts the analytics service object, makes API
  requests and returns the response. If any error occurs, the makeRequest
  method is retried using exponential backoff.

  Args:
    analytics: The analytics service object

  Returns:
    The API response from the makeRequest method.
  """
  for n in range(0, 5):
    try:
      return makeRequest(analytics)

    except HttpError, error:
      if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
                               'internalServerError', 'backendError']:
        time.sleep((2 ** n) + random.random())
      else:
        break

  print "There has been an error, the request never succeeded."