اسمحوا لي أن أعطيك راحة قصيرة.
حصلت لك هناك!
ما قصدت قوله هو،
اسمحوا لي أن أقدم لكم لمحة موجزة عن نقل الدولة التمثيلية.
ما هو الراحة بالضبط؟
كيف يمكننا الاستفادة منه في تطبيقنا الزاوي
وكيف يمكننا الاستفادة من هذا للتواصل مع الخادم؟
كيف يدعم الخادم واجهة برمجة تطبيقات REST
وكيف يمكننا الوصول إلى واجهة برمجة تطبيقات REST من تطبيق Angular الخاص بنا؟
دعونا نتحدث عن ذلك أكثر قليلا في هذا الدرس.
في هذه المحاضرة بالذات، سأقدم لك لمحة موجزة عن REST.
أنا متأكد من أنك سمعت مصطلح خدمات الويب المذكورة
في عالم تكنولوجيا المعلومات في كثير من الأحيان.
ما هي خدمات الويب بالضبط؟
خدمات الويب هي طريقة لتصميم الأنظمة لدعم التشغيل البيني بين
الأنظمة المتصلة عبر الشبكة، مثل الإنترنت كما نراه اليوم.
هذا ما نشير إليه على أنه بنية موجهة نحو الخدمات.
الآن، ما يعنيه هذا هو أنك توفر طريقة موحدة لجهازين
متصلين بالإنترنت لتكون قادرة على التواصل مع بعضها البعض.
مستوى تخطيط التطبيق
لتطبيقات قاعدة البيانات باستخدام المعايير المفتوحة.
الآن، لقد استخدمت الكثير من المصطلحات هناك.
دعونا نحاول كسرها
وفهم قليلا عن كل من ذلك في هذه المحاضرة.
طريقتان شائعتان يتم استخدامهما لدعم خدمات الويب هما SOAP، وهي
خدمات الويب المستندة إلى بروتوكول الوصول البسيط إلى الكائنات،
والتي تستخدم لغة وصف خدمات الويب
لتحديد كيفية اتصال نقطتي النهاية مع بعضهما البعض.
وعادة ما يعتمد الصابون على استخدام XML
كتنسيق للرسائل التي يتم تبادلها بين نقطتي النهاية.
يستخدم نقل الحالة التقديمية أو الراحة أيضًا معايير الويب، ولكن تبادل
البيانات بين نقطتي النهاية يمكن أن يكون إما XML أو بشكل متزايد.
باستخدام JSON كتنسيق.
تعتبر طريقة REST للتشغيل البيني أبسط مقارنة بـ SOAP،
وبالتالي وجدت REST نشرًا أوسع كثيرًا في خدمات الويب المتبقية.
عادة، يتم تسهيل اتصال خادم العميل باستخدام REST
حيث يدعم الخادم واجهة برمجة تطبيقات REST ويمكن للعميل بعد ذلك استدعاء
نقاط النهاية REST API الخاصة بهم للحصول على معلومات أو لتحميل المعلومات إلى الخادم.
مرة أخرى، لقد ذكرت الكلمة، استدعاء نقطة نهاية أبي ريست.
إذن هذه بعض المصطلحات التي استخدمتها.
دعونا توضيح بعض هذه في الشرائح القليلة القادمة.
نقل الحالة التمثيلية هو نمط من بنية البرمجيات التي
تم تصميمها خصيصا للوسائط التشعبية الموزعة عبر الشبكة العالمية.
الآن تم تقديم هذا لأول مرة من قبل روي فيلدنغ في أطروحة الدكتوراه.
الآن، هذه إحدى أطروحات الدكتوراه التي أنتجت
شيئًا مفيدًا للعالم.
لذلك وجد هذا مرة أخرى الكثير من الجر في عالم خدمات الويب.
هذه مجموعة من مبادئ الشبكة التي توضح كيفية توفير الموارد
على الخوادم، ويمكن الوصول إلى هذه الموارد من العملاء عن
طريق تحديد الموارد باستخدام نقاط النهاية REST API.
في إطار نقل الدولة التمثيلية هناك أربعة مبادئ تصميم أساسية.
أولاً وقبل كل شيء، تم إنشاء REST على بروتوكول HTTP.
لذلك يستخدم جميع أساليب HTTP التي رأيناها بالفعل في الدرس السابق.
ثانيًا، تم تصميم REST لتكون عديمة الجنسية، مما يعني أن الخادم لا يخزن
أي معلومات حول الحالة بعد اكتمال الاتصال.
لذلك عندما يتلقى الخادم الطلب، يستجيب الخادم
وبعد ذلك، فإنه لا يتذكر أي شيء أكثر عن تلك
المحادثة بين العميل والخادم.
ثالثًا، تتمثل طريقة REST لتوفير الموارد
في عرض بنية دليل مثل عناوين URL الموحدة لتحديد مواقع الموارد.
ورابع تنسيقها لتبادل البيانات هو عادة JSON أو
XML، أو كلاهما يمكن دعمه باستخدام REST.
أحد دوافع الارتفاع التي تشير إلى REST كوسيلة لدعم
خدمات الويب هو أنه يلتقط كل شيء جيد من جميع الشبكة العالمية.
وهذا جعل كلمة ويب ناجحة.
استخدام مؤشرات الموارد الموحدة أو محددات الموارد الموحدة، عناوين URL،
والتي تسمح لك بمعالجة الموارد عن طريق تحديدها كعنوان URL،
والثاني هو بروتوكول يركب فوق بروتوكول HTTP.
لقد عثر HTTP بالفعل على نشر واسع في الإنترنت.
ثالثًا، دورة استجابة الطلب التي تعرف HTTP بها.
لذلك تقوم بإرسال طلب، يتلقى الخادم طلبك، يعالج الطلب،
يرسل الاستجابة للطلب، ويتلقى هذا العميل الاستجابة،
يتصرف بناءً على ذلك، وقد ينشئ طلبات أخرى.
لذلك، هذا النهج من دورة استجابة الطلب هو راسخ جدا مع HTTP
وويب في جميع أنحاء العالم بروتوكول HTTP كما رأينا في وقت سابق،
وسوف نستخدم جميع الأفعال المختلفة التي يوفر HTTP.
على وجه التحديد، وضعت بوابة آخر حذف.
لكونها قادرة على تحديد العمليات التي يتعين القيام بها
على الموارد التي يتم تخزينها على جانب الخادم.
على سبيل المثال، إذا قمت بإجراء طلب HTTP GET، فأنت تطلب
من الخادم إرجاع المصدر.
إذا قمت بإجراء طلب POST، فأنت تطلب من الخادم إنشاء مورد جديد.
إذا قمت بإجراء طلب PUT، فأنت تطلب من الخادم تحديث
مورد موجود وإذا قمت بإصدار طلب حذف فأنت تطلب من
الخادم حذف المورد الذي تم تعريفه بواسطة عنوان URL المحدد هذا.
أيضا، فإنه يحاول الحفاظ على إديمبتنس.
بعض العمليات عندما يتم تنفيذها
حتى مرارا وتكرارا لن يسبب أي تغيير في الدولة.
بعض العمليات الأخرى، إذا قمت بها على التوالي،
فإنها قد تتسبب في تغيير الحالة.
لذلك عليك أن تكون حذرا حول العمليات التي يمكن أن تتكرر دون
أي عواقب ضارة.
والتي يجب أن يتم بعناية فائقة.
في عالم REST، غالبًا ما تسمع أشخاصًا يتحدثون عن الأسماء
والأفعال والتمثيلات.
الآن سنقوم بتوضيح كل واحد من هذه بمزيد من التفصيل في الشرائح القليلة القادمة.
الأسماء، على وجه التحديد، مليئة بالموارد
وعادة ما يتم تحديد هذه الموارد من خلال عنوان URL الخاص بها وهذه غير مقيدة.
الأفعال مقيدة وهذه الإجراءات المحددة التي يتعين القيام بها على الموارد.
والعروض التقديمية كما نرى عندما تحتاج المعلومات إلى نقلها
من الخادم إلى العميل أو
من العميل إلى الخادم، وكيفية ترميز المعلومات.
عادة إما باستخدام JSON أو استخدام XML.
المورد هو التجريد الرئيسي الذي يعمل REST حولها
بحيث يتم استخراج المعلومات في المورد.
ويتم تحديد المورد عن طريق تحديده باستخدام URI.
لذلك يمكن
تحديد أي معلومات يمكن تغليفها وإتاحتها كمورد.
قطعة من المعلومات مثل هذا الطقس الحالي في هونغ كونغ يمكن أن تكون مصدرا،
صورة يمكن أن تكون مصدرا.
يمكن أن تكون معلومات سعر السهم موردًا، وما إلى ذلك.
لذا، مهما كان ما تعرفه كجزء من المعلومات التي قد
يهتم بها العميل، يمكن تحديده كمورد.
يمكنك حتى التعامل مع الموارد كمجموعة من الموارد
التي قد يرسلها هذا الخادم إلى هذا العميل.
يتم توضيح مثال على كيفية تسمية الموارد هنا.
لذلك نستخدم عناوين URI لتحديد المصدر. إن
القراءة السريعة للمواصفات أو عناوين URL هنا
ستتيح لك بسهولة فهم ما نشير إليه باستخدام عناوين URL هذه.
على سبيل المثال، شيء ينتهي بالأطباق/،
تفترض تلقائيًا أن هذا يشير إلى مجموعة من الأطباق.
مثل الصحون/123 على سبيل المثال،
قد يعني الطبق رقم 123، في هذه الحالة وهلم جرا.
لذلك من السهل جدًا القول أنه يمكنك تحديد مجموعة من الموارد،
وتكون قادرًا على تحديدها كمجموعة، ثم تنزيلها كمجموعة.
أو، يمكنك تحديد مورد فردي،
وتقول أنك تريد هذا المورد معين.
الآن يمكن تنظيم هذه الموارد في التسلسل الهرمي
الذي مواصفات URI هذا.
حتى عندما كنت اجتياز المسار،
تذهب من أكثر عمومية إلى أكثر تحديدا من هذا المورد.
تمكنك بنية الدليل هذه من تحديد الموارد التي
توفرها من موقع الخدمة الخاص بك بسهولة بالغة.
الجزء الثاني من واجهة برمجة تطبيقات REST هي الكلمات. على
وجه الخصوص نحن مهتمون في 4 الأفعال من HTTP للحصول على،
وضع، نشر، وحذف.
في هذه الحالة سوف تكون هذه الأفعال قيلولة في الإجراءات التي
نريد أن يتم تنفيذها على المورد على جانب الخادم.
يعني GETT أنك تريد إجراء عملية قراءة على المورد، مما يعني
أن العميل الذي يرسل طلب get يشير إلى الخادم أنه يريد
الحصول على هذا العرض التقديمي لمصدر البيانات من موقع الخادم إلى موقع العميل.
تعني POST أنك تريد إنشاء مورد جديد ثم ستفعل.
حدد تفاصيل المورد في التمثيل، ولكن يتم استخدامه
لتحديد المورد.
ثم أرسل المعلومات إلى جانب الخادم،
بحيث يقوم الخادم بإنشاء المورد نيابة عنك.
سيكون PUT تعديل الموارد،
وحذف، كما تتوقع، هو حذف المصادر.
لذلك، كما ترون
يتم تعيين الأفعال الأربعة، بعد، وضع وحذف في عمليات CRUD الأربعة التي يمكنك تنفيذها
على قاعدة بيانات تخزن هذه الموارد على جانب الخادم.
قراءة، إنشاء، تحديث وحذف العمليات.
بمزيد من التفصيل، فإن HTTP GET هو طريقة للتحديد.
أن تريد المعلومات أو العرض التقديمي للمورد ليتم
إرجاعها إلى العميل من موقع الملقم.
لذلك عند إصدار طلب GET إلى نقطة نهاية REST API.
أنت تسأل إما عن مجموعة من الموارد التي يتم تقديمها بواسطة
Uri أو مورد معين يتم تحديده بواسطة معرف
تلك الموارد المعينة المحددة داخل عنوان URL كما ترى في هذا المثال،
إذا قمت بأطباق/452، فأنت تعني أن تقول أن الطبق رقم 452،
مع يجب إرجاع معرف 452 إلى جانب العميل.
وبالمثل، يتم استخدام عملية ما بعد، كما رأينا، لإنشاء المورد.
لذلك عند إنشاء المورد،
سيكون محتوى وصف المورد في شكل تمثيل JSON أو تمثيل XML، وسيتم
تضمينه في نص رسالة الطلب التي يتم إرسالها إلى جانب الخادم.
لذلك تتوقع عملية النشر تمثيلاً
للمورد بتنسيق JSON أو XML في نص رسالة الطلب.
ويتلقى الخادم رسالة الطلب هذه، يقوم الخادم بإنشاء هذا
المورد على جانب الخادم ثم يقوم بإرجاع تأكيد أو
خطأ للإشارة إلى فشل إنشاء المورد.
وبالمثل فإنه يضع عملية سهلة الاستخدام لتحديث مورد.
عند القيام بعملية PUT على مورد على جانب الخادم، يمكنك إرسال
التعديل مرة أخرى إما عن طريق تحديد التعديل الجزئي
الذي تريد التأثير على مورد معين في نص رسالة الرد فقط.
أو يمكنك إرسال التمثيل الكامل للمورد
في نص الرسالة، اعتمادًا على الترتيب بين العميل
والخادم، يتوقع الخادم أن يتم
تمرير المعلومات في نص رسالة الطلب.
حذف العملية كما تتوقع حذف المورد الموجود.
الآن في هذه الحالة بالذات، بالطبع، ستكون عملية الحذف لأنه
إذا حاولت حذف مورد وكان المورد موجودًا، فسيتم حذفه.
إذا كنت تحاول حذف مورد غير موجود،
فلن يتسبب ذلك في أي تعديل آخر على جانب الخادم باستثناء
أن الخادم سيرد بخطأ يقول أن المورد غير موجود.
ولكن مع ذلك، هو مثال على عملية في هذه الحالة.
وبالمثل، ستعمل عملية get أيضًا لأنها لا
تقوم بأي تعديل على المورد على موقع الخادم.
إدخال آخر بالطبع سوف لتعديل المورد على جانب الخادم.
تحتاج إلى إنشاء مورد جديد أو
تعديل مورد موجود على جانب الخادم، وبالطبع العروض التقديمية للبيانات.
كما كنت أؤكد، فإن الفرعين الشائعين
للتمثيل هما إما JSON XML، والجزء الأخير
الذي نحتاج إلى التأكيد عليه هو أن جانب الخادم يجب أن يكون عديم الجنسية تمامًا.
مما يعني أن جانب الخادم لا يتتبع حالة العميل.
لأنه، إذا كان الخادم يحتاج إلى تتبع حالة العميل، فإنه لن يكون قابلاً للتطوير.
لذا من أجل تنفيذ قابل للتطوير لجانب الخادم،
فإنك تستخدم عادةً خادمًا عديم الحالة على جانب الخادم.
لذلك إذا كان طلب العملاء المرسلة إلى الخادم سيتم التعامل معه
كطلب مستقل، ولن ينعكس على
الطلبات السابقة التي تم التعامل معها بالفعل من قبل الخادم من عميل معين.
لذلك فمن مسؤولية العميل لتتبع حالته الخاصة.
إما في شكل استخدام ملفات تعريف الارتباط أو استخدام قاعدة بيانات موقع العميل.
مهما كان يعني أن هذا مناسب.
الآن، هذا النهج حيث يتتبع العميل حالته الخاصة هو أكثر قابلية للتطوير،
لأن عميلك سيكون مسؤولاً عن تتبع حالته الخاصة.
وهذا هو المكان الذي يساعدنا إعداد MVC جانب العميل في هذا الصدد.
وأخيرًا لم ننتهي بعد من REST، سنرى المزيد من
REST في التمارين التي تلي هذا الدرس بالذات.
وبعد ذلك أيضًا،
سنرى المزيد من التفاصيل حول استخدام REST في بقية هذه الدورة.
[ موسيقى]