اسمحوا لي أن أعطيك راحة قصيرة. حصلت لك هناك.
ما قصدت قوله هو دعوني أقدم لكم
لمحة موجزة عن نقل الدولة التمثيلية
ما هو بالضبط ريست؟
كيف يمكننا الاستفادة منه في تطبيق React الخاص بنا،
وكيف يمكننا الاستفادة من هذا للتواصل مع الخادم؟
كيف يدعم الخادم واجهة برمجة تطبيقات REST،
وكيف يمكننا الوصول إلى واجهة برمجة تطبيقات REST من تطبيق React الخاص بنا؟
دعونا نتحدث عن ذلك أكثر قليلا في هذا الدرس.
أنا متأكد من أنك سمعت مصطلح خدمات الويب المذكورة في عالم تكنولوجيا المعلومات في كثير من الأحيان.
ما هي خدمات الويب بالضبط؟
خدمات الويب هي طريقة لتصميم أنظمة لدعم التشغيل البيني
بين الأنظمة المتصلة عبر شبكة مثل الإنترنت كما نراه اليوم.
هذا ما نشير إليه على أنه بنية موجهة نحو الخدمات.
الآن، ما يعنيه هذا هو أنك توفر
طريقة موحدة لجهازين متصلين بالإنترنت لتكون قادرة على
التواصل مع بعضها البعض على
مستوى طبقة التطبيقات للتطبيقات المستندة إلى الويب باستخدام معايير مفتوحة.
الآن، لقد استخدمت الكثير من المصطلحات هناك
دعونا نحاول كسرها وفهم
قليلا عن كل من ذلك في هذه المحاضرة.
نهجان شائعان يستخدمان لدعم خدمات الويب هما SOAP.
خدمات الويب المستندة إلى بروتوكول الوصول إلى الكائنات البسيطة
التي تستخدم لغة وصف خدمات الويب
لتحديد كيفية اتصال نقطتي النهاية مع بعضها البعض.
عادة ما يعتمد SOAP على استخدام XML
كتنسيق للرسائل التي يتم تبادلها بين نقطتي النهاية.
يستخدم نقل الحالة التمثيلية أو REST أيضًا معايير الويب،
ولكن يمكن أن يكون تبادل البيانات بين نقطتي النهاية إما XML أو
باستخدام JSON بشكل متزايد كتنسيق.
طريقة REST للتشغيل البيني أبسط مقارنة بـ SOAP، وبالتالي،
وجدت REST نشرًا أوسع كثيرًا في عالم خدمات الويب.
عادة، يتم
تسهيل اتصال العميل والخادم باستخدام REST حيث يدعم الخادم واجهة برمجة تطبيقات REST
ويمكن للعميل بعد ذلك استدعاء نقاط النهاية REST API
للحصول على معلومات أو لتحميل المعلومات إلى الخادم.
مرة أخرى، لقد ذكرت الكلمة استدعاء نقاط نهاية أبي ريست،
لذلك هذه هي بعض المصطلحات التي استخدمتها.
دعونا توضيح بعض هذه في الشرائح القليلة القادمة.
نقل الدولة التمثيلية هو نمط من بنية البرمجيات
التي تم تصميمها خصيصا للوسائط التشعبية الموزعة عبر الشبكة العالمية.
الآن تم تقديم هذا لأول مرة من قبل روي فيلدنغ في أطروحة الدكتوراه.
الآن هذه إحدى أطروحات الدكتوراه
التي أنتجت شيئًا مفيدًا للعالم.
لذلك وجد هذا مرة أخرى الكثير من الجر في عالم خدمات الويب.
هذه مجموعة من مبادئ الشبكة التي توضح كيفية
توفير الموارد على الخوادم
ويمكن الوصول إلى هذه الموارد من العملاء
عن طريق تحديد الموارد باستخدام نقاط نهاية API.
وفي إطار نقل الدولة التمثيلية،
هناك أربعة مبادئ أساسية للتصميم.
أولاً وقبل كل شيء، تم إنشاء REST على بروتوكول HTTP،
لذلك يستخدم جميع أساليب HTTP التي رأيناها بالفعل في الدرس السابق.
ثانيًا، تم تصميم REST لتكون عديمة الجنسية،
مما يعني أن الخادم لا يخزن أي معلومات حول
الحالة بعد اكتمال الاتصال.
لذلك عندما يتلقى الخادم الطلب، يستجيب الخادم،
وبعد ذلك لا يتذكر
أي شيء أكثر عن المحادثة بين العميل والخادم.
ثالثًا، تتمثل طريقة REST لتوفير الموارد
في عرض بنية دليل مثل عناوين URL (محددات الموارد الموحدة - عناوين URL).
رابعًا، يكون تنسيق تبادل البيانات عادةً JSON
أو XML أو يمكن دعم كليهما باستخدام REST.
أحد دوافع روي التي تقترح ريست كوسيلة لدعم خدمات الويب هو
أنه يلتقط كل الأشياء الجيدة حول
الشبكة العالمية والتي جعلت الشبكة العالمية ناجحة.
استخدام مؤشرات الموارد
الموحدة أو
محددات مواقع الموارد الموحدة (URL) التي تسمح لك بمعالجة الموارد من خلال تحديدها كعنوان URL.
والثاني، كونه بروتوكول يعيش على رأس بروتوكول HTTP.
لقد عثر HTTP بالفعل على نشر واسع في الإنترنت.
ثالثًا، دورة استجابة الطلب التي يعرف بها HTTP.
لذلك تقوم بإرسال طلب،
يتلقى الخادم طلبك، يعالج الطلب،
يرسل الاستجابة للطلب،
ويتلقى العميل الاستجابة،
ويعمل بناءً على ذلك، وقد ينشئ طلبات أخرى.
لذا، فإن هذا النهج لدورة استجابة الطلب
راسخ بشكل جيد للغاية مع HTTP وشبكة الويب العالمية.
الآن، بروتوكول HTTP كما رأينا في وقت سابق،
وسوف نستخدم جميع الأفعال المختلفة التي يوفر HTTP.
على وجه التحديد، GET و
PUT و POST و DELETE
لتتمكن من تحديد العمليات التي يجب القيام بها على الموارد المخزنة على جانب الخادم.
على سبيل المثال، إذا قمت بإجراء طلب HTTP GET،
فأنت تطلب من الخادم إرجاع المورد.
إذا قمت بإجراء طلب POST،
فأنت تطلب من الخادم إنشاء مورد جديد.
إذا قمت بإجراء طلب PUT،
فأنت تطلب من الخادم تحديث مورد موجود.
وإذا قمت بإصدار طلب DELETE،
فأنت تطلب من الخادم حذف المورد
الذي تم تعريفه بواسطة عنوان URL معين.
أيضا، فإنه يحاول الحفاظ على إديمبوتنس.
بعض العمليات، عندما يتم تنفيذها بشكل متكرر،
لن يسبب أي تغيير في الحالة.
بعض العمليات الأخرى، إذا قمت بها على التوالي،
فإنها قد تتسبب في تغيير الحالة.
لذلك عليك أن تكون حذرا حول العمليات التي يمكن أن تتكرر دون
أي عواقب ضارة والتي يجب القيام بها بعناية فائقة.
في عالم REST، غالبًا ما تسمع أشخاصًا يتحدثون عن الأسماء والأفعال والتمثيلات.
الآن، سنقوم بتوضيح كل واحدة من هذه بمزيد من التفصيل في الشرائح القليلة القادمة.
تشير الأسماء على وجه التحديد إلى الموارد
وعادة ما يتم تحديد هذه الموارد من خلال عناوين URL الخاصة بها وهذه غير مقيدة.
الأفعال هي القيد وهذه تحدد الإجراءات التي يتعين
القيام بها على الموارد والتمثيلات كما نرى.
عندما تحتاج المعلومات إلى نقلها
من الخادم إلى العميل أو من العميل إلى الخادم،
كيف يمكنك ترميز المعلومات.
عادة، إما باستخدام JSON أو باستخدام XML.
المورد هو التجريد الرئيسي الذي يعمل REST حولها.
لذلك، يتم استخراج المعلومات في شكل مورد
ويتم تحديد المورد عن طريق تحديده باستخدام عنوان URL.
لذا، يمكن
تحديد أي معلومات يمكن تضمينها وإتاحتها كمورد.
قطعة من المعلومات مثل الطقس الحالي في هونغ كونغ يمكن أن يكون موردًا،
يمكن أن تكون صورة
موردًا، يمكن أن تكون معلومات أسعار الأسهم موردًا وما إلى ذلك.
لذا، مهما كان ما تعرفه كجزء من المعلومات التي قد يهتم بها العميل،
يمكن تحديده كمورد.
يمكنك حتى التعامل مع الموارد كمجموعة من
الموارد التي قد يرسلها الخادم إلى العميل.
يتم توضيح مثال على كيفية تسمية الموارد هنا.
لذلك نستخدم عناوين URI لتحديد المصدر.
ستتيح لك القراءة السريعة لهذه المواصفات أو عناوين URI هنا بسهولة فهم ما نشير إليه باستخدام عناوين URI هذه.
لذلك، على سبيل المثال، شيء ينتهي بأطباق/،
تفترض تلقائيًا أن هذا يشير إلى مجموعة من الأطباق.
ولكن أطباق/123 على سبيل المثال،
قد يعني الطبق رقم 123 في هذه الحالة وهلم جرا.
لذلك، فمن السهل جدا لحفظ ويمكنك تحديد
مجموعة من الموارد وتكون قادرة على التعرف
عليها كمجموعة ومن ثم تحميلها كمجموعة أو يمكنك
تحديد مورد فردي ويقول أنك تريد هذا المورد معين.
الآن، يمكن تنظيم هذه الموارد في تسلسل هرمي لمواصفات URI هذا.
لذلك، أثناء اجتياز المسار،
تذهب من أكثر عمومية إلى أكثر تحديدا من المورد.
تمكنك بنية الدليل هذه من تحديد الموارد
التي تستخدمها أو توفرها من جانب الخادم الخاص بك بسهولة بالغة.
الجزء الثاني من واجهة برمجة تطبيقات REST هي الأفعال. على
وجه الخصوص، نحن مهتمون في الأفعال الأربعة من HTTP GET، PUT
، POST و DELETE.
في هذه الحالة، سيتم تعيين هذه الأفعال إلى الإجراءات التي
نريد أن يتم تنفيذها على المورد، على جانب الخادم.
يعني GET أنك تريد إجراء عملية قراءة على المورد.
لذا، مما يعني أن العميل الذي يرسل طلب GET يشير
إلى الخادم أنه يريد الحصول على تمثيل
لهذا المورد من جانب الخادم إلى جانب العميل.
تعني POST أنك تريد إنشاء
مورد جديد ثم ستقوم بتحديد تفاصيل المورد
في التمثيل المستخدم
لتحديد المورد ثم إرسال هذه المعلومات إلى جانب الخادم،
بحيث يقوم الخادم بإنشاء هذا المورد نيابة عنك.
سيكون PUT تعديل الموارد و
DELETE كما تتوقع هو حذف الموارد.
لذلك، كما ترون،
يتم تعيين الأفعال الأربعة؛ GET، POST، PUT و DELETE، في عمليات CRUD الأربعة التي يمكنك
تنفيذها على قاعدة بيانات تخزن هذه الموارد على جانب الخادم،
وعمليات القراءة، CREATE، UPDATE، و DELETE.
بمزيد من التفصيل، فإن HTTP GET هي طريقة لتحديد أنك
تريد
إرجاع المعلومات أو تمثيل المورد إلى العميل من جانب الخادم.
لذلك، عند إصدار طلب GET إلى نقطة نهاية REST API،
فأنت تطلب إما مجموعة من الموارد التي يمثلها
URI أو مورد معين يتم تعريفه بواسطة معرف هذا المورد
المعين، المحدد داخل عنوان URL.
لذا، كما ترى في هذا المثال،
إذا قلت، أطباق/452،
فأنت تعني أن تقول أن الطبق رقم 452 مع
معرف 452 يجب أن تعاد إلى جانب العميل.
وبالمثل، يتم استخدام عملية POST كما رأينا لإنشاء المورد.
لذلك، عند إنشاء المورد،
سيكون محتوى وصف المورد في شكل تمثيل JSON أو
تمثيل XML وسيتم تضمينه
في نص رسالة الطلب التي يتم إرسالها إلى جانب الخادم.
لذا، تتوقع عملية POST تمثيلاً
للمورد بتنسيق JSON أو XML في نص رسالة الطلب.
عندما يتلقى الملقم رسالة الطلب،
يقوم الملقم بإنشاء هذا المورد على جانب الخادم ثم يقوم
بإرجاع أو خطأ للإشارة إلى فشل إنشاء المورد.
وبالمثل، يتم استخدام عملية PUT لتحديث مورد.
عند القيام بعملية PUT على مورد على جانب الخادم،
يمكنك إرسال التعديل مرة أخرى
إما عن طريق تحديد التعديل الجزئي الذي تريد التأثير على
مورد معين في نص رسالة الرد أو يمكنك إرسال
التمثيل الكامل في نص الرسالة.
اعتمادا على الترتيب بين العميل والخادم،
يتوقع الملقم المعلومات التي سيتم تمريرها في نص رسالة الطلب.
تقوم عملية DELETE كما تتوقع بحذف المورد الموجود.
الآن، في هذه الحالة بالذات،
بالطبع عملية DELETE ستكون idempotent لأنه إذا
حاولت حذف مورد وكان المورد موجودًا، فسيتم حذفه.
إذا كنت تحاول حذف مورد غير موجود،
فلن يتسبب ذلك في أي تعديل آخر على جانب الخادم،
باستثناء أن الخادم سيرد بخطأ يقول أن المورد غير موجود.
ولكن، مع ذلك، DELETE هو مثال على عملية idempotent في هذه الحالة.
وبالمثل، فإن عملية GET هي أيضًا عملية idempotent لأنها
لا تجري أي تعديلات على المورد على جانب الخادم.
ستقوم POST و PUT بالطبع بتعديل المورد على جانب الخادم،
إما إنشاء مورد جديد أو تعديل مورد موجود على جانب الخادم.
وبطبيعة الحال، فإن التمثيلات،
كما كنت أؤكد،
فإن التنسيقين الشائعين للتمثيل هما إما JSON أو XML.
الجزء الأخير الذي نحتاج إلى التأكيد عليه هو
أن جانب الخادم يجب أن يكون عديم الجنسية تمامًا،
مما يعني أن جانب الخادم لا يتتبع
حالة العميل لأنه إذا كان الخادم يحتاج إلى تتبع حالة العملاء،
فلن يكون قابلاً للتطوير.
لذلك، لتنفيذ قابل للتحجيم من جانب الخادم،
عادة ما تستخدم خادم عديم الحالة على جانب الخادم.
لذلك، سيتم
التعامل مع كل طلب يرسله العميل إلى الخادم كطلب مستقل
ولن ينعكس على الطلبات السابقة
التي تم التعامل معها بالفعل من قبل الخادم من هذا العميل المحدد.
لذلك، من مسؤولية العميل تتبع حالته الخاصة،
إما في شكل استخدام ملفات تعريف الارتباط أو استخدام قاعدة بيانات من جانب العميل،
مهما كانت الوسائل المناسبة.
الآن، هذا النهج حيث يتتبع العميل حالته الخاصة
هو أكثر قابلية للتطوير لأن كل عميل فردي
سيكون مسؤولاً عن تتبع حالته الخاصة.
هذا هو المكان الذي يساعدنا فيه إعداد MVC من جانب العميل في هذا الصدد.
وأخيرًا، لم ننتهي بعد من REST.
سنرى المزيد من REST في التدريبات التي تتبع في هذا الدرس بالذات،
ثم سنرى المزيد من التفاصيل حول استخدام REST في بقية هذه الدورة.