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