نظرة عامة على الراحة. الجزء الثاني: التواصل بين العميل والخادم

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

• العملاء - العملاء؛
• الطلبات - طلبات العملاء؛
• العناصر - البضائع.

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

الطلبات

يتم إجراء طلبات العميل دائمًا تقريبًا عبر HTTP. بشكل عام، تتكون طلبات HTTP من عدة مكونات:

• طريقة HTTP؛
• عنوان؛
• أوري؛
• هيئة الطلب.

أدناه سننظر في كل جزء مكون بمزيد من التفصيل.

URI والموارد

تسمى البيانات التي يحصل عليها العملاء أو يعدلونها من خلال الطلبات بالموارد. أساس التفاعل بين العميل والخادم هو معالجة الموارد. الموارد في REST هي أي شيء يمكن تسميته. بمعنى ما، هذه تشبه الفصول الدراسية في Java. في Java يمكننا إنشاء فئة لأي شيء. الأمر نفسه في REST - يمكن أن يكون المورد أي شيء: مستخدم، أو مستند، أو تقرير، أو أمر. كل هذا يمكن أن يكون إما تجريدًا لبعض الكيانات أو شيئًا ملموسًا، على سبيل المثال، ملف - صورة، فيديو، رسوم متحركة، ملف PDF. على سبيل المثال، لدينا 3 موارد:

• العملاء - العملاء؛
• الطلبات - طلبات العملاء؛
• العناصر - البضائع.

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

• /clients - URI لجميع العملاء الحاليين؛
• /clients/23 - URI لعميل معين، أي العميل ذو المعرف = 23؛
• /clients/4 - URI لعميل معين، أي العميل ذو المعرف=4.

ولكن هذا ليس كل شيء. يمكننا توسيع URI عن طريق إضافة أوامر إليه:

• /clients/4/orders - معرف URI لجميع طلبات العميل رقم 4؛
• /clients/1/orders/12 - معرف URI للطلب رقم 12 للعميل رقم 1.

إذا واصلنا هذه السلسلة وأضفنا السلع، نحصل على:

• /clients/1/orders/12/items — URI لقائمة جميع المنتجات بالترتيب رقم 12 التي قدمها العميل رقم 1.

مع مستويات التداخل، المفتاح هو جعل عناوين URI بديهية.

طريقة HTTP

أسلوب HTTP (أسلوب HTTP باللغة الإنجليزية) عبارة عن تسلسل لأي أحرف، باستثناء عناصر التحكم والفواصل، التي تشير إلى العملية الرئيسية على المورد. هناك العديد من طرق HTTP الشائعة. ندرج تلك التي يتم استخدامها غالبًا في خدمات RESTful:

• GET - يُستخدم للحصول على معلومات حول مورد معين (عبر المعرف) أو مجموعة من الموارد؛
• POST - يُستخدم لإنشاء مورد جديد؛
• PUT - يستخدم لتغيير المورد (عبر المعرف)؛
• DELETE - يستخدم لحذف مورد (عبر المعرف).

العناوين

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

• نص - نص/عادي، نص/CSS، نص/HTML؛
• صورة - صورة/png، صورة/jpeg، صورة/gif؛
• الصوت - الصوت/WAV، الصوت/MPEG؛
• فيديو - فيديو/MP4، فيديو/OGG؛
• التطبيق - application/json، application/pdf، application/xml، application/octet-stream.

في المجمل، قد يحتوي الطلب على العنوان التالي:

Accept:application/json

يخبر هذا الرأس الخادم أن العميل يتوقع تلقي استجابة بتنسيق JSON.

هيئة الطلب

رسالة يرسلها العميل إلى الخادم. يعتمد ما إذا كان الطلب يحتوي على نص أم لا على نوع طلب HTTP. على سبيل المثال، عادةً لا تحتوي طلبات GET وDELETE على أي نص طلب. لكن PUT وPOST يمكن أن يحتويا على: الأمر كله يتعلق بالغرض الوظيفي لنوع الطلب. بعد كل شيء، لتلقي البيانات وحذفها بواسطة المعرف (الذي يتم إرساله في عنوان URL)، لا تحتاج إلى إرسال بيانات إضافية إلى الخادم. ولكن لإنشاء مورد جديد (طلب POST)، تحتاج إلى نقل هذا المورد. الأمر نفسه ينطبق على تعديل مورد موجود. في REST، غالبًا ما يتم استخدام تنسيقات XML أو JSON لنقل نص الطلب. التنسيق الأكثر شيوعًا هو JSON. لنفترض أننا نريد إرسال طلب إلى الخادم، وإنشاء مورد جديد فيه. إذا كنت تتذكر، فقد نظرنا كمثال إلى أحد التطبيقات التي تدير طلبات العملاء. لنفترض أننا نريد إنشاء عميل جديد. في حالتنا، نقوم بتخزين المعلومات التالية عن العملاء: الاسم البريد الإلكتروني رقم الهاتف ثم يمكن أن يكون نص هذا الطلب هو JSON التالي:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

تجميع الطلبات معًا

لذلك، نظرنا في ما يمكن أن يتكون منه طلب العميل. دعونا الآن نعطي بعض الأمثلة على الاستعلامات مع الأوصاف

الإجابات

دعنا نقول بضع كلمات عن استجابات الخادم. تتكون الإجابة عادةً من الأجزاء التالية:

• رمز الاستجابة؛
• رؤوس؛
• هيئة الاستجابة.

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

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

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

• 201 مخلوق؛
• 401 غير مصرح به؛
• 507 تخزين غير كاف.

يتعلم العميل من رمز الاستجابة نتائج طلبه ويحدد الإجراءات التي يجب اتخاذها بعد ذلك. تنقسم رموز الاستجابة إلى عدة مجموعات:

• 1ХХ - إعلامية؛
• 2ХХ - الإبلاغ عن حالات القبول والمعالجة الناجحة لطلب العميل؛
• 3XX - أبلغ العميل أنه لإكمال العملية بنجاح، من الضروري تقديم طلب آخر، عادةً باستخدام عنوان URI مختلف؛
• 4ХХ - خطأ العميل. على سبيل المثال، طلب تم إنشاؤه بشكل غير صحيح أو رمز 404 Not Found المعروف، والذي يمكن أن يحدث عندما يطلب العميل موردًا غير موجود؛
• 5ХХ - خطأ في الخادم. يتم إرجاعها إلى العميل في حالة فشل العملية بسبب خطأ الخادم.

يمكنك قراءة المزيد عن جميع الرموز هنا . الجزء 1: ما هو REST الجزء 3: إنشاء خدمة RESTful في Spring Boot