مشكلة رموز حالة HTTP

يمكن وضع الموقف مع رموز استجابة HTTP في الأوزان والمقاييس: هذا ما يحدث عندما يواجه مطورو المواصفات ذوي النوايا الحسنة الواقع القاسي. حتى مع حقيقتين وحشيتين.

كما ناقشنا في الفصل العاشر ، فإن أحد أهداف الأخطاء الدلالية هو مساعدة العميل على فهم سبب الخطأ. في تطوير مواصفات HTTP (على وجه الخصوص ، RFC 7231 ) ، كان من الواضح أن هذا الهدف كان أحد الأهداف الرئيسية. علاوة على ذلك ، فإن القيود المعمارية لـ REST كما وصفها Fjelding في أطروحته تشير إلى أنه ليس فقط العملاء يجب أن يفهموا دلالات الخطأ ، ولكن جميع وكلاء الشبكة (الوكلاء) بين العميل والخادم في بنية "متعددة الطبقات". ووفقًا لهذا ، فإن تسميات رموز حالة HTTP تصف بالتفصيل تقريبًا أي مشكلة قد تحدث مع طلب HTTP: قيم Accept-*



رأس غير صالحة ، مفقودةContent-Length



وطريقة HTTP غير مدعومة وعنوان URI طويل جدًا وما إلى ذلك.

ولكن مع ما لا يساعده RFC على الإطلاق - يتعلق الأمر بالسؤال ، ما الذي يجب أن يفعله العميل أو الوكيل بالضبط مع وجود خطأ. كما ناقشنا ، يمكن استعادة الأخطاء أو عدم استردادها. إذا كانت الأخطاء قاتلة ، فإن العملاء عمومًا لا يهتمون بكل هذا البقدونس برموز الحالة والعناوين ، وحتى أكثر من الوكلاء الوسيطة. لهذا ، في الواقع ، ستكون ثلاثة رموز كافية:

• 400
  
  
  
  للأخطاء المستمرة (إذا كررت الطلب فقط ، فلن ينتقل الخطأ إلى أي مكان) ؛
• 404
  
  
  
  لحالة عدم اليقين (قد تؤدي إعادة محاولة الطلب إلى نتيجة مختلفة) ؛
• 500
  
  
  
  لمشكلات جانب الخادم بالإضافة إلى رأس Retry-After
  
  
  
  لإعلام العميل بموعد العودة.

ملاحظة جانبية : بالمناسبة ، انتبه لمشكلة تصميم المواصفات. بشكل افتراضي ، 4xx



لا يتم تخزين جميع الرموز مؤقتًا ، باستثناء: 404



، 405



، 410



، ، 414



. ليس لدينا شك في أن هذا تم بحسن نية ، لكننا نشك في أن عدد الأشخاص الذين يعرفون هذه الدقة يساوي تقريبًا عدد محرري المواصفات. نتيجة لذلك ، لدينا العديد من المواقف (قام المؤلف شخصيًا 404



بإلقاء نظرة على عواقب إحداها) ، عندما تم إرجاع -ki بشكل خاطئ ، لكن العميل قام بتخزينها مؤقتًا ، وبالتالي تمديد fakup لفترة غير محددة.

بالنسبة للمشكلات القابلة للإصلاح ، نعم ، تساعد رموز الحالة بطريقة ما. بعضها محدد تمامًا ، على سبيل المثال 411 Length Required



. والبعض لا. هناك العديد من المواقف حيث يتم إخفاء العديد من الأخطاء تحت رمز واحد:

• 400 Bad Request
  
  
  
  للحالات التي تكون فيها بعض المعلمات مفقودة أو تحتوي على قيمة غير صالحة. هذا الخطأ عديم الفائدة تمامًا للعملاء ، ما لم تحدد الاستجابة الحقل المحدد الذي يحتوي على قيمة غير صالحة - وهذا هو بالضبط ما لا يوحده المعيار! نعم ، بالطبع ، يمكنك وضع معيار بنفسك - لكن هذا على الأقل يتعارض مع فكرة الشفافية في REST.

  
  
  
  
  
  
  

  NB: , 400
  
  
  
  , .. URI, , JSON .., 422 Unprocessable Entity



412 Precondition Failed
  
  
  
  . , .

  
  
  
  
  
  
  

• 403 Forbidden
  
  
  
  / . Forbidden
  
  
  
  -, :

  
  
  
  
  
  
  
  • — ;
  • — ;
  • — ;
  • — ;
  • — - .
  
  
  

  403
  
  
  
  , (, ) .

  
  
  
  
  
  
  

• 409 Conflict
  
  
  
  ;

  
  
  
  
  
  
  

• .

  
  
  
  
  
  
  

, / , — , 400



-, .

: , : ‘The response message will usually contain a representation that explains the status’. , , , , ( - ?), REST: , «» , .

, : - «» HTTP, . . Web - . , , , , , -. : , - — .

, . ¯\_(ツ)_/¯. — 401 Unauthorized



: WWW-Authenticate



— , , , , .. — Basic



(-, - Web 1.0, ). , , realm



- — . 401



— WWW-Authenticate



, , .

: - HTTP , ; ; - , . ( , , — , , , .) , , 200



-.

?

:

• REST RPC. - HTTP . :

  
  
  
  
  
  
  
  • 200 OK
    
    
    
    , — 200
    
    
    
    .
  • 500 Internal Server Error
    
    
    
    .
  
  
  

  400 Bad Request
  
  
  
  . , API Gateway;

  
  
  
  
  
  
  

• « » — , , , . ; — - . .
  
  NB: , : RPC- , , - - (, 403



429
  
  
  
  , - - , HTTP). , , , «» . ;

  
  
  
  
  
  
  

• . , :

  
  
  
  
  
  
  
  • HTTP- , HTTP (.. 406 Unacceptable



Accept-Language
    
    
    
    , , - );
  • , HTTP ( , ; ) — , - X-My-API-Error-Reason
    
    
    
    ;
  • , . - ( );
  • , -, , .
  
  
  

, , #3 .

- تمت كتابة هذا النص كجزء من إعداد القسم المستقبلي على HTTP API لكتابي ، ويجري العمل على GitHub .

النسخة الإنجليزية من نفس النص هنا .

سأكون ممتنًا إذا تعثر شخص ما على reddit ، فأنا لا أستطيع وفقًا لقواعد reddit.