أشكال الأخطاء
هناك ثلاثة أشكال. اقرأ الحالة أولاً ثم الجسم. 1.detail نص (معظم الأخطاء).
detail كائن يحمل code ثابتاً (اعتمد على code وليس على الرسالة).
code وmessage في المستوى الأعلى، دون detail. تأتي هذه من محدد المعدل، ومعالج المسار غير المعروف، والمعالج الشامل للأخطاء غير المتوقعة.
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قبل إعادة الإرسال، أو اقبل التكرار.