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

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

• العملاء (العملاء)
• أوامر (أوامر العملاء)
• العناصر (المنتجات)

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

الطلبات

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

• طريقة HTTP
• header
• URI
• هيئة الطلب

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

عناوين URI والموارد

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

• العملاء (العملاء)
• أوامر (أوامر العملاء)
• العناصر (المنتجات)

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

• /customers — معرف URI لجميع العملاء المتاحين
• /customers/23 — URI لعميل معين، أي العميل ذو المعرف=23
• /customers/4 — URI لعميل معين، أي العميل ذو المعرف=4.

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

• /customers/4/orders - معرف URI لجميع الطلبات المقدمة من العميل رقم 4
• /customers/1/orders/12 — معرف URI للطلب رقم 12 الذي قدمه العميل رقم 1.

إذا واصلنا التوسع بإضافة المزيد من المنتجات، نحصل على:

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

عندما نضيف مستويات التداخل، فإن الشيء المهم هو جعل عناوين URI بديهية.

طريقة 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" : "+1 (222) 333-4444"
}

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

لذلك، قمنا بفحص ما قد يكون في طلب العميل. وسنقدم الآن بعض الأمثلة للطلبات مع الأوصاف

استجابات

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

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

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

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

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

• 201 تم الإنشاء
• 401 غير مصرح به
• 507 تخزين غير كاف

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

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

نظرة عامة على الراحة. الجزء 3: إنشاء خدمة RESTful على Spring Boot