نظرية REST API

انتهت الوحدة الأولى بإنشاء طلب HTTP وإرساله والحصول على رد.

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

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

هذا ما سنفعله في الوحدة الثانية. لنذهب!

النظرية العامة

لنبدأ بالنظرية.

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

API

API - واجهة برمجة التطبيقات . هذا وصف للطرق التي يمكن للعميل والخادم من خلالها التواصل مع بعضهما البعض. نفتح وثائق API ونتعلم من هناك كيفية الحصول على البيانات اللازمة من الخادم.

نريد دائمًا أن يكون هذا التفاعل بسيطًا ومفهومًا. هذا يبسط المهمة لكل من المطورين (لا حاجة لإعادة اختراع العجلة عند تصميم خدمة جديدة) والمستخدمين (الخدمة أسهل بكثير لمعرفة ما إذا كانت تعمل على نفس مبدأ الخدمات المألوفة سابقًا). وهنا يجدر تذكر مصطلح جديد - REST.

راحة

REST - اختصار لنقل الدولة التمثيلية . قد لا يبدو الأمر واضحًا للغاية ، ولكن ببساطة ، REST هو أسلوب التفاعل (تبادل المعلومات) بين العميل والخادم.

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

وفقًا لذلك ، يُطلق على واجهة برمجة التطبيقات التي تم تطويرها مع مراعاة مبادئ REST اسم REST API ، وتسمى التطبيقات نفسها RESTful

سنقوم بإنشاء تطبيقات RESTful فقط ، لذلك يجدر مناقشة المبادئ التي سيلتزمون بها على الفور.

مبادئ الراحة

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

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

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

واجهة موحدة . يحدد المبدأ تنسيقًا واحدًا للتفاعل بين العميل والخادم. يجب أن تكون بنية جميع الطلبات متطابقة. يجب إرسال البيانات بنفس النموذج بغض النظر عمن يطلبها.

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

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