بقية العاطفة ل 200

لقد أردت منذ زمن طويل أن أكتب هذا المقال. ظللت أتساءل عن الجانب الذي يجب إدخاله بشكل صحيح. ولكن ، فجأة ، في الآونة الأخيرة ، ظهر مقال مماثل على حبري ، الذي تسبب في عاصفة في كوب. أكثر ما أثار دهشتي هو حقيقة أن المقال بدأ يتم طرحه في السلبيات ، على الرغم من أنه لم يعلن حتى عن شيء ما ، بل أثار مسألة استخدام أكواد استجابة خادم الويب في REST. اندلع النقاش الساخن. وكان التفسير هو أن المقالة دخلت في مسودة ... كيلوبايت من التعليقات والآراء ، إلخ. اختفى للتو. أصبح العديد من ضحايا كارمو ، والنظر ، من أجل لا شيء :)

بشكل عام ، كان مصير تلك المقالة هو ما دفعني إلى كتابة هذا المقال. وآمل حقًا أن تكون مفيدة وتوضيح الكثير.

أنا أحذرك ، كل شيء مكتوب أدناه هو تجربة حقيقية ، وليس فعل التوازن المعرفي. وهكذا ، قادوا.

HTTP

أول شيء فعله هو فصل الطبقات بوضوح تام. طبقة النقل هي http. حسنا ، في الواقع الراحة. هذا شيء مهم في قبول كل شيء و "نفسك" فيه. دعونا نتحدث فقط عن المتشعب أولا.

لقد استخدمت مصطلح "طبقة النقل". وأنا لم تبدي تحفظا. الشيء هو أن http نفسه ينفذ وظائف نقل الطلبات إلى الخادم والمحتوى إلى العميل ، بغض النظر عن tcp / ip. نعم ، يعتمد على tcp / ip. وما شابه ، تحتاج إلى اعتباره وسيلة نقل. لكن لا. وهذا هو السبب - اتصالات المقبس ليست مباشرة ، أي هذا ليس اتصال خادم عميل. يمكن لكل من طلب http واستجابة http أن تقطع شوطًا كبيرًا من خلال الكثير من الخدمات. يمكن تجميعها أو تحللها على العكس. قد يكون مؤقتا ، قد يتم تعديلها.

أي كل من طلب http واستجابة http لهما طريقهما الخاص. ولا يعتمد على النهاية الخلفية ولا على النهاية الأمامية. أطلب منك أن تولي اهتماما خاصا لهذا.

طرق http ليست ثابتة. يمكن أن تكون معقدة للغاية. على سبيل المثال ، إذا تم تضمين موازن في البنية التحتية ، فيمكنه إرسال الطلبات المستلمة إلى أي من العقد الخلفية. في الوقت نفسه ، يمكن للخلفية نفسها تنفيذ استراتيجيتها الخاصة للتعامل مع الطلبات. سيذهب بعضهم مباشرة إلى خدمات microservices مباشرة ، وسيتم معالجة بعضها بواسطة خادم الويب نفسه ، وسيتم استكمال بعضها ونقلها إلى شخص آخر ، وسيتم إصدار بعضها من ذاكرة التخزين المؤقت ، إلخ. هذه هي الطريقة التي يعمل بها الإنترنت. لا جديد

وهنا من المهم أن نفهم - لماذا نحتاج إلى رموز استجابة؟ الشيء هو أن النموذج بأكمله الموصوف أعلاه يتخذ قرارات بناءً عليها. أي هذه هي الرموز التي تسمح لك باتخاذ قرارات البنية التحتية والنقل أثناء توجيه http.

على سبيل المثال ، إذا واجه الموازن رمز استجابة من النسخ الاحتياطي 503 ، عند إرسال طلب ، فيمكنه اتخاذ هذا كسبب للاعتقاد بأن العقدة غير متاحة مؤقتًا. ألاحظ أن الاستجابة بالكود 503 توفر رأسًا لإعادة المحاولة. بعد استلام الفاصل الزمني من الرأس للاستقصاء المتكرر ، سيترك الموازن العقدة بمفرده للفترة المحددة وسيعمل مع العناصر المتاحة. علاوة على ذلك ، يتم تنفيذ هذه الاستراتيجيات "خارج الصندوق" بواسطة خوادم الويب.

offtopic صغير لعمق الفهم - ماذا لو استجابت العقدة 500؟ ماذا يجب أن تفعل الموازن؟ التبديل إلى آخر؟ وسوف يجيب الكثير - بالطبع ، جميع الأسباب 5xx لتعطيل العقدة. وسوف تكون خاطئة. رمز 500 هو رمز خطأ غير متوقع. أي واحد قد لا يحدث مرة أخرى. والأهم من ذلك ، قد لا يؤدي التبديل إلى عقدة أخرى إلى تغيير أي شيء. أي نحن ببساطة تعطيل العقد دون أدنى فائدة.

في حالة 500 ، تأتي الإحصاءات لمساعدتنا. يمكن لخادم WEB المحلي للعقدة أن يترجم العقدة نفسها إلى حالة عدم توفر مع وجود عدد كبير من الإجابات 500. في هذه الحالة ، سيتلقى موازن الاتصال بهذه العقدة استجابة 503 ولن يمسها. والنتيجة هي نفسها ، ولكن الآن ، هذا الحل ذو مغزى ويزيل الاستجابات "الخاطئة".

لكن هذا ليس كل شيء. في هذه الحالة ، سوف تسمح المراقبة للمشرفين بالاتصال بالموقف للحفاظ على العقدة. أي لا نحصل فقط على تنفيذ خدمة يمكن الوصول إليها بشكل كبير ، مع موازنات ، وما إلى ذلك ، ولكن أيضًا عملية دعم فعالة.

وكل هذا يسمح لك بعمل رموز استجابة للخادم. يجب أن تبدأ أي بنية تطبيق WEB بتصميم طبقة النقل. آمل ألا يكون هناك شك في ذلك.

الراحة

سأطرح سؤالا بلاغيا - ما هو؟ وماذا أجبت عليه؟ لن أقدم روابط لبراهين واضحة ، ولكن على الأرجح ليس الأمر كما هو في الواقع :) هذا مجرد أيديولوجية وأسلوب. بعض الاعتبارات حول الموضوع - أفضل طريقة للتواصل مع الظهر. وليس فقط التواصل ، ولكن التواصل في البنية التحتية WEB. أي بناء على http. مع كل هذه "الأشياء المفيدة" التي كتبت عنها أعلاه. القرارات النهائية لتنفيذ واجهة الخاص بك هي دائما لك .

هل تساءلت يومًا عن سبب عدم اختراع عملية نقل منفصلة لـ REST؟ على سبيل المثال ، ل websocket هو عليه. نعم ، يبدأ أيضًا بـ http ، ولكن بعد إنشاء الاتصال ، تكون هذه أغنية منفصلة بشكل عام. لماذا لا تفعل الشيء نفسه بالنسبة للراحة؟

الجواب بسيط - لماذا؟ هناك بروتوكول جميل ، جاهز ، تم التحقق منه - http. انها جداول جيدا. يتيح لك تنفيذ خدمات معقدة يمكن الوصول إليها بشكل كبير يمكنها تحمل عبء ثقيل. كل ما هو مطلوب هو إدخال بعض القواعد المفاهيمية بحيث يفهم المطورون بعضهم البعض.

من هنا يتبع استنتاج بسيط وواضح - كل ما هو متأصل في http هو متأصل في REST. هذه كيانات لا تنفصل. لا يوجد رأس REST منفصل ، ولا حتى تلميح بأن REST هو REST. بالنسبة لأي خادم REST ، يكون الطلب مطابقًا تمامًا لأي خادم آخر. أي REST هو فقط ما لدينا في الاعتبار.

رموز استجابة HTTP REST

دعونا نتحدث عن الكود الذي يجب أن يستجيب له خادمك لطلب REST؟ شخصيا ، يبدو لي أنه من كل ما سبق ، الجواب واضح بالفعل ، لأنه REST لا يختلف عن أي طلب آخر ، يجب أن يخضع لنفس القواعد تمامًا. يعد رمز الاستجابة جزءًا لا يتجزأ من REST ويجب أن يكون ذا صلة بجوهر الرد. أي إذا لم يتم العثور على الكائن حسب الطلب ، فسيكون 404 ، إذا قدم العميل طلبًا غير صحيح 400 ، إلخ. ولكن في معظم الأحيان ، لا ينتهي النقاش هناك. لذلك ، سأستمر.

هل من الممكن الإجابة على كل شيء بالكود 200؟ ومن سيمنعك؟ من فضلك ... الكود 200 هو نفس الكود مثل الآخرين. صحيح أن أساس هذا النهج هو أطروحة بسيطة للغاية - نظامي مثالي ، ولا يوجد به أخطاء. إذا كنت شخصًا قادرًا على إنشاء مثل هذه الأنظمة - فلا يمكن تحسدها إلا!

لكن على الأرجح ... إنها ليست مثالية. والأخطاء تحدث. ويحدث حدوثها بسبب ظروف خارجة عن إرادتنا. وهنا الحل النموذجي هو إنشاء نظام ترميز الأخطاء الخاص بك. هل هذا سيء؟ نعم هذا سيء. هذا سيء للغاية. دعونا معرفة السبب.

وهكذا ، مع الأخذ الكود 200 كواحد صحيح ، فإننا نتحمل مسؤولية تطوير الطبقة الكاملة (الطبقة الحرجة) للنظام - معالجة الأخطاء. أي يتم إرسال عمل الكثير من الناس لتطوير هذه الطبقة إلى الخردة. ويبدأ بناء "دراجته". لكن هذا البناء الضخم محكوم عليه بالفشل.

لنبدأ بالكود. إذا أردنا الإجابة على الـ 200 ، فسوف يتعين علينا نحن أنفسنا التعامل مع الأخطاء. الطريقة الكلاسيكية هي محاولة يبني. كل قطعة كود نلفها برمز إضافي. معالجات الذين يفعلون شيئا مفيدا. على سبيل المثال ، وضعوا شيئا في السجل. شيء مهم. سوف توطين الخطأ. وإذا حدث الخطأ لا حيث كان متوقعا؟ أو إذا حدث خطأ في معالج الأخطاء؟ أي هذه الاستراتيجية على مستوى الرمز لا تعمل بشكل مسبق. وفي النهاية ، سيقوم المترجم أو النظام الأساسي بمعالجة الأخطاء الخاصة بك. نظام التشغيل أخيرا. جوهر الخطأ هو أنك لا تنتظر ذلك. لا تحتاج لإخفائه ، فأنت بحاجة إلى العثور عليه وإصلاحه. لذلك ، إذا كان REST يستجيب لبعض الطلبات مع وجود خطأ 500 ، فهذا أمر طبيعي . وما هو أكثر من ذلك ، أليس كذلك .

دعنا نعود إلى السؤال - لماذا هذا صحيح؟ لأن:

1. الرمز 500 هو رمز مميز للبنية التحتية يمكن على أساسه تعطيل العقدة التي تحدث بها المشكلة ؛
2. أكواد 5xx هي ما يتم مراقبته وإذا حدث مثل هذا الرمز ، فإن أي نظام مراقبة سيعلمك على الفور بهذا. وستكون خدمة الدعم في الوقت المناسب قادرة على الاتصال بحل المشكلة ؛
3. أنت لا تكتب رمز إضافي. لا تضيع وقتك الثمين في هذا الشأن. لا تعقيد الهندسة المعمارية. أنت لا تتعامل مع مشاكل غير عادية بالنسبة لك - تكتب رمز التطبيق. ماذا يريدون منك ما الذي يدفعون مقابله؟
4. التتبع الذي يقع عن طريق الخطأ 500 سيكون أكثر فائدة من محاولاتك لتجاوزه.
5. إذا قام طلب REST بإرجاع رمز 500 ، فإن الواجهة بالفعل في وقت معالجة الاستجابة ستعرف ما هي الخوارزمية لمعالجتها. علاوة على ذلك ، لن يتغير جوهر المسألة بأي شكل من الأشكال ، فأنت لم تتلق أي شيء معقول سواء من 200 أو من 500. ولكن من 500 تلقيت ربحًا - إدراك أن هذا خطأ غير متوقع.
6. رمز 500 سيأتي مع ضمان. بغض النظر عن مدى سوء أو جيد كتبته رمزك. هذا هو نقطة ارتكاز.

بشكل منفصل ، سوف أقوم بإدخال مسمار في "كامل" الكود 200:

7. حتى لو حاولت بشدة تجنب رموز الاستجابة الأخرى من الخادم بخلاف 200 لطلباتك ، لا يمكنك القيام بذلك. يمكن لأي خادم وسيط الاستجابة لطلبك مع أي رمز تماما. وعليك معالجة مثل هذه الإجابة بشكل صحيح.

المجموع ، على المستوى المنطقي ، الصراع على الكود 200 لا معنى له.

الآن دعنا نعود إلى مستوى البنية التحتية. في كثير من الأحيان أسمع الرأي - رمز 5xx ليس مستوى التطبيق ، لا يمكن أن تعطى الدعم. مهم ، حسنا ... هناك تناقض في البيان نفسه. يمكنك إعطاء. لكن هذا الرمز ليس مستوى تطبيق. هذا صحيح أكثر. لفهم هذا ، أقترح النظر في القضية:

أنت تنفذ بوابة. لديك العديد من البلدان النامية ، ولكل منها قناة اتصال خاصة بها لخدمة خاصة معينة. حسنًا ، على سبيل المثال ، للدفع عبر VPN. وهناك قناة تواصل مع الإنترنت. تتلقى طلبًا لإجراء عملية مع بوابة ، لكن ... الخدمة غير متوفرة.

وماذا يجب أن تجيب؟ لمن؟ هذه مشكلة في البنية التحتية ، وعلى وجه التحديد ، واجهت النسخ الاحتياطي فيها. بالطبع ، تحتاج إلى الإجابة بجرأة 503. ستؤدي هذه الإجراءات إلى حقيقة أن الموازن سيتم تعطيل بواسطة الموازن لبعض الوقت. في نفس الوقت ، فإن الموازن ، إذا تم تكوينه بشكل صحيح ، دون قطع الاتصال مع العميل ، سيرسل الطلب إلى عقدة أخرى. و ... تلقى العميل النهائي ، بدرجة عالية من الاحتمال ، 200. وليس وصفًا مخصصًا للخطأ الذي لن يساعده بأي شكل من الأشكال.

أين وما رمز للاستخدام

السؤال ليس بسيطا. لا يوجد إجابة محددة لذلك. لكل نظام ، يتم تصميم طبقة النقل وقد تكون الرموز الموجودة فيها محددة.

هناك معايير مقبولة. يمكن العثور عليها بسهولة ، ومرة ​​أخرى ، لن أقدم أدلة واضحة. ولكن ، سأعطيك غير واضح - developer.mozilla.org/en/docs/Web/HTTP/Status
لماذا هو؟ الشيء هو أن معالجات الكود يمكن أن يتصرفوا بشكل مختلف ، وهذا يتوقف على التنفيذ وسياق "فهم الكود". على سبيل المثال ، لدى المتصفحات استراتيجية للتخزين المؤقت تعتمد على رموز الاستجابة. وبعض الخدمات لها رموز خاصة بها. على سبيل المثال ، CloudFlare.

أي عند اتخاذ القرارات بشأن استخدام الأكواد ، يجب أن تعتمد على جميع العناصر المدرجة في طبقة النقل من الكود الخاص بك في الخلف إلى الكود على العميل. هذه هي الطريقة الوحيدة للعثور على الإجابات الصحيحة. لن أحاول حتى إعطاء الجميع حبة عالمية هنا.

جذور الشر

هذا هو المشروع الثالث الذي جئت إليه من الكود 200 في REST. إنها معاناة. لا توجد كلمة أخرى. إذا كنت تقرأ بعناية كل شيء حتى اللحظة الحالية ، فأنت تدرك بالفعل أنه بمجرد أن يبدأ المشروع بالنمو ، فإنه يحتاج إلى تطوير البنية التحتية ، واستدامته. رمز 200 يقتل كل هذه المحاولات في مهدها. وأول شيء عليك القيام به هو كسر الصور النمطية.

يبدو لي أن جذر الشر يكمن في حقيقة أن الكود 500 هو أول شيء يواجهه مطور ويب في مسيرته المهنية. يمكن القول إصابة طفولة. وكل جهوده في البداية تلاشت للحصول على الكود 200.

بالمناسبة ، لسبب ما ، في نفس المرحلة ، يتطور رأي قوي بأن الإجابات بالكود 200 فقط يمكن تزويدها بالجسم. بالطبع ، هذا ليس كذلك ، وأي إجابة قد "تأتي" مع أي رمز. الرمز هو رمز. الجسم هو الجسم.

علاوة على ذلك ، مع تطوير المطور ، فإنه يحتاج إلى إدارة أخطاء تطبيقه الخاص. ولكن ... ، وقال انه لا يعرف كيفية استخدام السجلات. لا يمكن تكوين خادم الويب. هو يدرس. وأولئك "العظماء" جداً يولدون. لأنها متوفرة له ويمكنه أن يصنعها بسرعة. علاوة على ذلك ، على هذا "العظيم" يصعد عجلات جديدة ، ويقوي الإطار ، إلخ. ويصبح هذا الشخص العظيم رفيقه لفترة طويلة بما فيه الكفاية ، حتى ... حتى يكون لديه مهام معقدة متعددة المكونات. وهنا ، كما يقولون - يُحظر الدخول إلى السوبرماركت مع التزلج "الكبير" والأسطوانة.

ملاحظة: قام مؤلف المقالة المذكورة باستعادتها من المسودات - habr.com/en/post/440382 ، حتى تتمكن من التعرف عليها أيضًا.

PPS: لقد حاولت توضيح جميع جوانب الحاجة إلى استخدام رموز الاستجابة ذات الصلة في REST. لن أرد على التعليقات ، يرجى فهم لي بشكل صحيح. سوف أقرأها باهتمام كبير ، لكن ليس لدي ما أضيفه. شكرا جزيلا لك على التحلي بالصبر بما فيه الكفاية لقراءة المقال!