Skip to main content

أشكال الأخطاء

هناك ثلاثة أشكال. اقرأ الحالة أولاً ثم الجسم. 1. detail نص (معظم الأخطاء).
2. detail كائن يحمل code ثابتاً (اعتمد على code وليس على الرسالة).
3. code وmessage في المستوى الأعلى، دون detail. تأتي هذه من محدد المعدل، ومعالج المسار غير المعروف، والمعالج الشامل للأخطاء غير المتوقعة.
يحمل خطأ المخطط 422 قائمة في detail، بإدخال واحد لكل حقل غير صالح:
يحدد loc موضع الخطأ: ["body", "reference"] لجسم JSON، و["query", "environment"] أو ["path", "key"]. وفي حقل نموذج multipart يكون العنصر الأول هو body أيضاً. تعامل مع الأشكال الثلاثة جميعاً: العميل الذي يفترض أن detail كائن دائماً سيفشل عند أول خطأ 422.

معرّف الطلب

تحمل كل استجابة الترويسة X-Request-ID. إذا أرسلت معرّفك الخاص (من 1 إلى 64 حرفاً من A-Z a-z 0-9 . _ : -) أعادته Sahl، وإلا أنشأت معرّفاً. تُدرج كل مكالمة بمفتاح في Developers, Call log في وحدة التحكم تحت هذا المعرّف. اذكره عند مراسلة Sahl.

الفهرس

400 طلب غير صالح

401 غير مصرح

403 محظور

404 غير موجود

413 الحمولة كبيرة جداً

422 تعذّرت المعالجة

قيمة kind الخاطئة ليست خطأً: تُعامل القيم غير المعروفة على أنها individual.

429 طلبات كثيرة جداً

تحمل كل استجابة ناجحة أيضاً X-RateLimit-Limit وX-RateLimit-Remaining. الحد يُطبق لكل عنوان IP للعميل وليس لكل مفتاح، لذا تتشاركه عدة خوادم خلف عنوان واحد. القيمة 100 في الدقيقة هي الافتراضية في الشيفرة وقد تتغير.

500 و502

تعذّر الوصول إلى القارئ ليس خطأً: يرد /extract بالحالة 200 مع reader_unavailable: true. راجع قراءة المستندات.

إعادة المحاولة

لا يوفر API مفتاح idempotency. فكّر في كل مكالمة قبل إعادتها. قواعد عملية:
  • لا تعد محاولة أي 4xx، باستثناء 429 الخاص بـ rate_limit_exceeded الذي يحمل Retry-After. فأي 4xx سيفشل بالطريقة نفسها.
  • أعد محاولة 5xx وانتهاء مهلة الشبكة مع تراجع أسي وحد أقصى، مثلاً 2 ثانية ثم 4 ثم 8، ثم توقف.
  • اضبط مهلة العميل أعلى بكثير من زمن الاستجابة المعتاد. تستخدم الأمثلة 120 ثانية لـ /extract.
  • بعد انتهاء المهلة في /extract لا تعرف هل نُفذت القراءة. تحقق من Documents بحثاً عن reference قبل إعادة الإرسال، أو اقبل التكرار.