أهلاً! سنتعرف اليوم على موضوع مثير للاهتمام للغاية، والأهم من ذلك، أنه مطلوب بشدة في سوق العمل: REST. سنقسم نظرتنا العامة عن REST إلى ثلاثة أجزاء:
في الجزء الأول، سنغطي تاريخ REST ونصف المبادئ التي يرتكز عليها REST.
في الجزء الثاني، سننظر في كيفية حدوث الاتصال بين العميل والخادم عبر بروتوكول HTTP.
وفي الثالث سنكتب تطبيق RESTful صغير سنختبره باستخدام برنامج يسمى "Postman".
هذه المقالة مخصصة للقراء الذين يعرفون المصطلحات التالية:
HTTP
عنوان URL وURI
JSON و(بدرجة أقل) XML
حقن التبعية
الجزء 1. ما هو الراحة؟
REST، مثل الكثير في عالم تكنولوجيا المعلومات، هو اختصار. وهو مشتق من "نقل الحالة التمثيلية" . هذا هو النمط المعماري للتفاعل بين مكونات النظام الموزع في شبكة الكمبيوتر. ببساطة، يحدد REST نمط التفاعل (تبادل البيانات) بين المكونات المختلفة للنظام، والتي يمكن أن يوجد كل منها فعليًا في أماكن مختلفة. هذا النمط المعماري عبارة عن مجموعة متسقة من القيود التي يتم الالتزام بها عند تصميم نظام موزع. تسمى هذه القيود أحيانًا بالمبادئ التوجيهية لـ REST. ليس هناك الكثير، فقط 6. سنتحدث عنهم بعد قليل.
التطبيقات التي تم إنشاؤها مع وضع مبادئ REST في الاعتبار، أي تلك التي لا تنتهك قيود REST، تسمى "RESTful".
تاريخ الراحة
تم تقديم مصطلح REST بواسطة Roy Fielding، أحد مبدعي بروتوكول HTTP، في رسالة الدكتوراه. أطروحته بعنوان "الأنماط المعمارية وتصميم معماريات البرمجيات القائمة على الشبكات" في عام 2000. على الرغم من أن مصطلح REST لا يزال من الممكن تسميته بالشباب، إلا أن المفهوم الذي يمثله يكمن في جوهر شبكة الويب العالمية. لن نتعمق في تاريخ هذا المصطلح. إذا كنت ترغب في الغوص في المصادر الأولية، قم بإلقاء نظرة على أطروحة
فيلدينغ .
قيود ومبادئ REST
كما هو مذكور أعلاه، يحدد REST كيفية تفاعل مكونات النظام الموزع مع بعضها البعض. بشكل عام، يحدث هذا من خلال عملية الطلب والاستجابة. يسمى المكون الذي يرسل الطلب بالعميل ، ويسمى المكون الذي يعالج الطلب ويرسل استجابة إلى العميل بالخادم . يتم إرسال الطلبات والاستجابات غالبًا عبر بروتوكول HTTP. يرمز HTTP إلى بروتوكول نقل النص التشعبي. عادة، الخادم هو بعض تطبيقات الويب. يمكن للعميل أن يكون أي شيء تقريبًا. على سبيل المثال، تطبيق جوال يطلب البيانات من الخادم. أو متصفح يرسل طلبات من صفحة ويب إلى خادم لتنزيل البيانات. قد يطلب التطبيق "أ" بيانات من التطبيق "ب". في هذه الحالة، يكون "أ" عميلًا بالنسبة إلى "ب"، ويكون "ب" خادمًا بالنسبة إلى "أ". وفي الوقت نفسه، يمكن لـ "أ" معالجة الطلبات الواردة من "ب" و"ج" و"د" وما إلى ذلك. في هذه الحالة، يكون التطبيق A خادمًا وعميلًا. كل شيء يعتمد على السياق. هناك شيء واحد مؤكد: المكون الذي يرسل الطلب هو العميل. المكون الذي يتلقى الطلب ويعالجه ويستجيب له هو الخادم. ومع ذلك، ليس كل نظام تتواصل مكوناته من خلال عملية الطلب والاستجابة هو نظام RESTful. لكي يعتبر النظام RESTful، يجب أن يتوافق مع قيود REST الستة:
1. بنية خادم العميل
هذا القيد يتعلق بفصل الاهتمامات. من الضروري فصل متطلبات واجهة العميل عن متطلبات الخادم الذي يقوم بتخزين البيانات. هذا القيد يجعل كود العميل أكثر قابلية للنقل إلى منصات أخرى، كما أن تبسيط جانب الخادم يحسن قابلية التوسع للنظام. إن التمييز بين "العميل" و"الخادم" يسمح بتطويرهما بشكل مستقل عن بعضهما البعض.
2. عديمي الجنسية
تتطلب بنية RESTful استيفاء الشروط التالية. في الفترة بين الطلبات، يجب ألا يقوم الخادم بتخزين معلومات حول حالة العميل والعكس صحيح. يجب أن يتم تكوين جميع الطلبات المقدمة من العميل بطريقة توفر للخادم جميع المعلومات اللازمة لإكمال الطلب. وبالتالي، يمكن لكل من الخادم والعميل "فهم" أي رسالة مستلمة، دون الاعتماد على الرسائل السابقة.
3. قابلة للتخزين المؤقت
يمكن للعملاء تخزين استجابات الخادم مؤقتًا. وهذه بدورها يجب أن يتم تصنيفها بشكل صريح أو ضمني على أنها مخزنة مؤقتًا أو غير مخزنة مؤقتًا، بحيث لا يتلقى العملاء بيانات قديمة أو غير صحيحة استجابة للطلبات اللاحقة. يساعد التخزين المؤقت الصحيح على إزالة بعض تفاعلات خادم العميل كليًا أو جزئيًا، مما يزيد من أداء النظام وقابلية التوسع.
4. واجهة موحدة
تتضمن المتطلبات الأساسية لبنية RESTful واجهة موحدة وموحدة. يجب أن يفهم العميل دائمًا التنسيق والعناوين التي يحتاج إلى استخدامها عند إرسال الطلب، ويجب على الخادم بدوره أن يفهم أيضًا التنسيق الذي يجب أن يستخدمه عند الاستجابة لطلبات العميل. يعد هذا التفاعل المتسق بين العميل والخادم الذي يصف ماذا وأين وبأي شكل وكيفية إرسال البيانات بمثابة واجهة موحدة.
5. الطبقات
نعني بالطبقات الهيكل الهرمي للشبكة. في بعض الأحيان يمكن للعميل التواصل مباشرة مع الخادم، وفي بعض الأحيان يتواصل فقط مع عقدة وسيطة. يمكن أن يؤدي استخدام الخوادم الوسيطة إلى زيادة قابلية التوسع بفضل موازنة التحميل والتخزين المؤقت الموزع. دعونا نقدم مثالا. تخيل تطبيقًا للجوال يحظى بشعبية كبيرة في جميع أنحاء العالم. يتضمن جزء لا يتجزأ من التطبيق تحميل الصور. يبلغ عدد مستخدميه الملايين، لذا لا يستطيع خادم واحد التعامل مع مثل هذا الحمل الثقيل. سيؤدي فصل النظام إلى طبقات إلى حل هذه المشكلة. إذا طلب العميل صورة من عقدة وسيطة، فإن العقدة الوسيطة تطلب الصورة من الخادم الأقل تحميلًا في الوقت الحالي وتعيد الصورة إلى العميل. إذا تم تطبيق التخزين المؤقت بشكل صحيح على كل مستوى من التسلسل الهرمي، فيمكن تحقيق قابلية التوسع الجيدة للنظام.
6. الكود حسب الطلب (اختياري)
يشير هذا القيد إلى أنه يمكن للعميل توسيع وظائفه عن طريق تنزيل التعليمات البرمجية من الخادم في شكل تطبيقات صغيرة أو نصوص برمجية.
مزايا الهندسة المعمارية RESTful
تتمتع التطبيقات التي تتوافق مع جميع القيود المذكورة أعلاه بالمزايا التالية: الموثوقية (لا حاجة لحفظ حالة العميل، والتي قد يتم فقدانها)
سنقسم نظرتنا العامة عن REST إلى ثلاثة أجزاء:
GO TO FULL VERSION