المؤشر
الرمز
رموز الخطأ الأساسية لواجهات برمجة التطبيقات gRPC
في بعض الأحيان، قد تنطبق رموز أخطاء متعددة. يجب أن تعرض الخدمات رمز الخطأ الأكثر تحديدًا الذي ينطبق. على سبيل المثال، استخدِم OUT_OF_RANGE
بدلاً من FAILED_PRECONDITION
إذا كان كلا الرمزين ينطبقان. وبالمثل، يُفضَّل استخدام NOT_FOUND
أو ALREADY_EXISTS
بدلاً من FAILED_PRECONDITION
.
عمليات التعداد | |
---|---|
OK |
ليس خطأ، بل يتم إرجاعه عند نجاح العملية. تعيين HTTP: 200 OK |
CANCELLED |
تم إلغاء العملية، عادةً من قِبل المتصل. تعيين HTTP: 499 طلب إغلاق العميل |
UNKNOWN |
حدث خطأ غير معروف. على سبيل المثال، قد يتم عرض هذا الخطأ عندما تكون قيمة تعيين HTTP: 500 خطأ في الخادم الداخلي |
INVALID_ARGUMENT |
حدّد العميل وسيطة غير صالحة. يُرجى العلم أنّ هذا يختلف عن تعيين HTTP: 400 طلب غير صالح |
DEADLINE_EXCEEDED |
انتهت المهلة قبل اكتمال العملية. بالنسبة إلى العمليات التي تغيّر حالة النظام، قد يتم عرض هذا الخطأ حتى إذا اكتملت العملية بنجاح. على سبيل المثال، قد يكون قد تأخّر ردّ ناجح من الخادم لفترة طويلة بما يكفي لانتهاء المهلة. تعيين HTTP: انتهت مهلة الوكيل 504 |
NOT_FOUND |
لم يتم العثور على بعض الكيانات المطلوبة (مثل الملف أو الدليل). ملاحظة لمطوّري الخوادم: في حال رفض طلب لفئة كاملة من المستخدمين، مثل طرح الميزة تدريجيًا أو قائمة مسموح بها غير موثَّقة، يمكن استخدام تعيين HTTP: 404 لم يتم العثور عليه |
ALREADY_EXISTS |
الكيان الذي حاول العميل إنشاؤه (مثل ملف أو دليل) متوفّر مسبقًا. تعيين HTTP: 409 تعارض |
PERMISSION_DENIED |
المتصل ليس لديه إذن لتنفيذ العملية المحدّدة. يجب عدم استخدام تعيين HTTP: 403 محظور |
UNAUTHENTICATED |
لا يتضمّن الطلب بيانات اعتماد مصادقة صالحة للعملية. تعيين HTTP: 401 غير مصرّح به |
RESOURCE_EXHAUSTED |
تم استنفاد بعض الموارد، ربما حصة لكل مستخدم، أو ربما نفدت المساحة في نظام الملفات بالكامل. تعيين HTTP: 429 Too Many Requests |
FAILED_PRECONDITION |
تم رفض العملية لأنّ النظام ليس في الحالة المطلوبة لتنفيذ العملية. على سبيل المثال، الدليل الذي سيتم حذفه غير فارغ، أو تم تطبيق عملية rmdir على عنصر غير دليل، وما إلى ذلك. يمكن لمنفّذِي الخدمة استخدام الإرشادات التالية لاختيار بين تعيين HTTP: 400 طلب غير صالح |
ABORTED |
تم إلغاء العملية، عادةً بسبب مشكلة في التوافق، مثل تعذُّر التحقّق من التسلسل أو إلغاء المعاملة. اطّلِع على الإرشادات أعلاه لتحديد ما إذا كنت تريد استخدام تعيين HTTP: 409 تعارض |
OUT_OF_RANGE |
تمّت محاولة إجراء العملية بعد النطاق المسموح به. على سبيل المثال، الانتقال إلى ما بعد نهاية الملف أو قراءته على عكس الخطأ هناك قدر كبير من التداخل بين تعيين HTTP: 400 طلب غير صالح |
UNIMPLEMENTED |
لم يتم تنفيذ العملية أو أنها غير متاحة أو مفعَّلة في هذه الخدمة. تعيين HTTP: 501 Not Implemented |
INTERNAL |
الأخطاء الداخلية وهذا يعني أنّه تمّ انتهاك بعض الشروط الثابتة التي يتوقّعها النظام الأساسي. تم حجز رمز الخطأ هذا للأخطاء الخطيرة. تعيين HTTP: 500 خطأ في الخادم الداخلي |
UNAVAILABLE |
هذه الخدمة غير متاحة حاليًا. من المرجّح أنّ هذا الموقف عابر، ويمكن تصحيحه من خلال إعادة المحاولة مع الانتظار. يُرجى العِلم أنّه ليس من الآمن دائمًا إعادة محاولة العمليات غير الثابتة. اطّلِع على الإرشادات أعلاه لتحديد ما إذا كنت تريد استخدام تعيين HTTP: 503 الخدمة غير متاحة |
DATA_LOSS |
ثمة بيانات تالفة أو مفقودة ويتعذّر استرجاعها. تعيين HTTP: 500 خطأ في الخادم الداخلي |
الحالة
يحدِّد نوع Status
نموذج خطأ منطقيًا مناسبًا لبيئات البرمجة المختلفة، بما في ذلك واجهات برمجة التطبيقات REST وRPC. ويستخدمه gRPC. تحتوي كل رسالة Status
على ثلاث قطع من البيانات: رمز الخطأ ورسالة الخطأ وتفاصيل الخطأ.
يمكنك الاطّلاع على مزيد من المعلومات عن نموذج الخطأ هذا وكيفية التعامل معه في دليل تصميم واجهة برمجة التطبيقات.
الحقول | |
---|---|
code |
رمز الحالة الذي يجب أن يكون قيمة فهرسية |
message |
رسالة خطأ موجّهة للمطوّرين، ويجب أن تكون باللغة الإنجليزية. يجب ترجمة أي رسالة خطأ موجّهة للمستخدم وإرسالها في الحقل |
details[] |
قائمة بالرسائل التي تتضمّن تفاصيل الخطأ هناك مجموعة شائعة من أنواع الرسائل لاستخدام واجهات برمجة التطبيقات. |