برنامج تعليمي حول خدمات الويب RESTful: مثال على واجهة برمجة تطبيقات REST

لماذا نستخدم خدمات الويب RESTful؟

قبل الخوض في التفاصيل التقنية، من المفيد فهم سبب شيوع تقنية REST. وقد برزت خدمات الويب RESTful للأسباب التالية:

1. اللغات والبيئات غير المتجانسة – هذا أحد الأسباب الأساسية، وهو نفس السبب الذي رأيناه لـ صابون كذلك.

• فهو يُمكّن تطبيقات الويب المبنية على لغات برمجة مختلفة من التواصل مع بعضها البعض.
• بفضل خدمات RESTful، يمكن أن تتواجد تطبيقات الويب هذه في بيئات مختلفة؛ بعضها قد يكون على Windows، والبعض الآخر يمكن أن يكون على نظام التشغيل Linux.

في النهاية، وبغض النظر عن البيئة، يجب أن تكون النتيجة واحدة دائمًا: يجب أن تكون التطبيقات قادرة على التواصل فيما بينها. توفر خدمات الويب RESTful هذه المرونة للتطبيقات المبنية على لغات برمجة ومنصات متنوعة.

تُظهر الصورة أدناه مثالاً على تطبيق ويب يتطلب التواصل مع تطبيقات أخرى مثل فيسبوك وتويتر و... Google.

إذا كان تطبيق العميل بحاجة للعمل مع مواقع مثل فيسبوك وتويتر، فعادةً ما يحتاج المطورون إلى معرفة لغة البرمجة والمنصة التي بُنيت عليها هذه المواقع. وبناءً على ذلك، يمكنهم كتابة كود الربط، لكن هذا الأسلوب قد يكون صعب الصيانة للغاية.

بدلاً من ذلك، فيسبوك، وتويتر، و Google تُتيح هذه الخدمات عرض وظائفها على شكل خدمات ويب RESTful. وهذا يسمح لأي تطبيق عميل باستدعاء هذه الخدمات عبر REST بغض النظر عن التقنية المستخدمة.

2. حدث الأجهزة - في الوقت الحاضر، كل شيء يحتاج إلى العمل عليه الهاتف الأجهزة، سواء كانت هاتفًا محمولًا أو جهاز كمبيوتر محمولًا أو حتى نظام سيارة.

تخيل حجم الجهد المطلوب لبرمجة تطبيقات على هذه الأجهزة للتواصل مع تطبيقات الويب العادية. مرة أخرى، تُسهّل واجهات برمجة تطبيقات RESTful هذه المهمة، لأنه كما ذُكر في النقطة الأولى، لا تحتاج فعليًا إلى معرفة الطبقة الأساسية للجهاز.

3. حدث الحوسبة السحابية – كل شيء ينتقل إلى الحوسبة السحابية. التطبيقات تنتقل تدريجياً إلى أنظمة قائمة على الحوسبة السحابية مثل Azure or Amazon. Azure و Amazon توفر العديد من واجهات برمجة التطبيقات (APIs) المبنية على بنية RESTful. لذا، بات من الضروري تطوير التطبيقات بطريقة تجعلها متوافقة مع الحوسبة السحابية. وبما أن جميع البنى السحابية تعمل وفق مبدأ REST، فمن المنطقي برمجة خدمات الويب وفقًا لبنية REST لتحقيق أقصى استفادة من الخدمات السحابية.

العناصر الأساسية المريحة

لقد قطعت خدمات الويب REST شوطاً طويلاً منذ نشأتها. في عام 2002، أصدر اتحاد الويب تعريف خدمات الويب WSDL وSOAP، والذي شكّل معياراً لكيفية تنفيذ خدمات الويب.

في عام 2004، أصدر اتحاد الويب تعريفًا لمعيار إضافي يُسمى RESTful. على مدى السنوات القليلة الماضية، اكتسب هذا المعيار شعبية واسعة، ويُستخدم الآن من قِبل العديد من أشهر المواقع الإلكترونية حول العالم، بما في ذلك فيسبوك وتويتر.

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

العناصر الأساسية لتطبيق RESTful هي كما يلي:

1. المصادر – العنصر الأساسي الأول هو المورد نفسه. لنفترض أن تطبيق ويب على خادم ما يحتوي على سجلات لعدة موظفين. لنفترض أن URL جزء من تطبيق الويب هو https://demo.guru99.comالآن، للوصول إلى مورد سجل الموظف عبر خدمات REST، يمكن إصدار الأمر https://demo.guru99.com/employee/1يُخبر هذا الأمر خادم الويب بتقديم تفاصيل الموظف الذي رقمه الوظيفي هو 1.
2. طلب الأفعال تُحدد هذه الأوامر ما تريد فعله بالمورد. يُصدر المتصفح أمر GET لإعلام نقطة النهاية برغبته في الحصول على البيانات. مع ذلك، تتوفر العديد من الأفعال الأخرى، بما في ذلك POST وPUT وDELETE. لذا، في حالة المثال المذكور https://demo.guru99.com/employee/1في الواقع، يقوم متصفح الويب بإصدار فعل GET لأنه يريد الحصول على تفاصيل سجل الموظف.
3. طلب الرؤوس – هذه تعليمات إضافية تُرسل مع الطلب. وقد تحدد نوع الاستجابة المطلوبة أو تفاصيل التفويض.
4. طلب الهيئة هذه هي البيانات المُرسلة مع الطلب. تُرسل البيانات عادةً في نص الطلب عند إرسال طلب POST إلى خدمة الويب REST. في طلب POST، يُخبر العميل خدمة الويب REST برغبته في إضافة مورد إلى الخادم. وبالتالي، يحتوي نص الطلب على تفاصيل المورد المطلوب إضافته.
5. هيئة الاستجابة هذا هو الجزء الرئيسي من الاستجابة. لذا، في مثال واجهة برمجة تطبيقات RESTful، إذا أردنا الاستعلام من خادم الويب عبر الطلب https://demo.guru99.com/employee/1قد يقوم خادم الويب بإرجاع مستند XML يحتوي على جميع تفاصيل الموظف في نص الاستجابة.
6. رموز حالة الاستجابة – هذه هي الرموز العامة التي يتم إرجاعها مع استجابة خادم الويب. مثال على ذلك الرمز 200، والذي يتم إرجاعه عادةً عندما لا يكون هناك خطأ أثناء إرجاع الاستجابة إلى العميل.

طرق مريحة

يوضح الرسم البياني أدناه معظم الأفعال (POST و GET و PUT و DELETE) ومثال REST API لما تعنيه.

لنفترض أن لدينا خدمة ويب RESTful معرفة في الموقع https://demo.guru99.com/employeeعندما يرسل العميل أي طلب إلى هذه الخدمة الإلكترونية، يمكنه تحديد أي من أفعال HTTP المعتادة: GET، POST، DELETE، وPUT. فيما يلي ما سيحدث إذا أرسل العميل هذه الأفعال.

1. سأعين – سيتم استخدام هذا لإنشاء موظف جديد باستخدام خدمة الويب RESTful.
2. للحصول على – سيتم استخدام هذا للحصول على قائمة بجميع الموظفين الذين يستخدمون خدمة الويب RESTful.
3. ضع – سيتم استخدام هذا لتحديث جميع الموظفين الذين يستخدمون خدمة الويب RESTful.
4. حذف – سيتم استخدام هذا لحذف جميع الموظفين الذين يستخدمون خدمة RESTful.

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

1. سأعين – هذا لن يكون قابلاً للتطبيق، لأننا نقوم بجلب بيانات الموظف رقم 1، وهو موجود بالفعل.
2. للحصول على – سيتم استخدام هذا للحصول على تفاصيل الموظف رقم 1 باستخدام خدمة الويب RESTful.
3. ضع – سيتم استخدام هذا لتحديث تفاصيل الموظف رقم 1 باستخدام خدمة الويب RESTful.
4. حذف – يُستخدم هذا لحذف تفاصيل الموظف رقم 1.

مريح Architecture

يتميز التطبيق أو البنية التي تعتبر متوافقة مع REST أو على نمط REST بالخصائص التالية.

1. تنقسم الحالة والوظيفة إلى موارد موزعة هذا يعني أنه يجب أن يكون الوصول إلى كل مورد ممكنًا عبر أوامر HTTP المعتادة: GET، POST، PUT، أو DELETE. فإذا أراد شخص ما الحصول على ملف من خادم، فعليه إرسال طلب GET والحصول على الملف. وإذا أراد تحميل ملف على الخادم، فعليه إرسال طلب POST أو PUT. وأخيرًا، إذا أراد حذف ملف من الخادم، فعليه إرسال طلب DELETE.

2. البنية هي بنية العميل/الخادم، عديمة الحالة، متعددة الطبقات، وتدعم التخزين المؤقت.

• الخادم والعميل هو البنية النموذجية حيث يمكن أن يكون الخادم هو خادم الويب الذي يستضيف التطبيق، ويمكن أن يكون العميل بسيطًا مثل متصفح الويب.
• يعني "عديم الحالة" أن حالة التطبيق لم يتم الحفاظ عليها في REST. على سبيل المثال، إذا قمت بحذف مورد من خادم باستخدام الأمر DELETE، فلا يمكنك أن تتوقع أن يتم تمرير معلومات الحذف إلى الطلب التالي.

لضمان حذف المورد، ستحتاج إلى إرسال طلب GET. يُستخدم طلب GET أولاً للحصول على جميع الموارد الموجودة على الخادم، وبعد ذلك يجب التحقق مما إذا كان المورد قد حُذف بالفعل.

المبادئ والقيود المريحة

تعتمد بنية REST على بعض الخصائص، والتي سيتم شرحها بالتفصيل أدناه. يجب أن تتوافق أي خدمة ويب RESTful مع هذه الخصائص حتى تُصنف على أنها RESTful. تُعرف هذه الخصائص أيضًا بمبادئ التصميم التي يجب اتباعها عند العمل مع الخدمات القائمة على RESTful.

1. خادم العميل المريح

   

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

2. عديم الجنسية

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

3. مخبأ

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

4. نظام الطبقات

يقوم مفهوم النظام متعدد الطبقات على إمكانية إضافة طبقة وسيطة، مثل طبقة البرمجيات الوسيطة، بين العميل والخادم الذي يستضيف خدمة الويب RESTful. (تُنشأ جميع منطق الأعمال في طبقة البرمجيات الوسيطة، وقد تكون هذه خدمة إضافية يتفاعل معها العميل قبل استدعاء خدمة الويب). ولكن يجب أن يكون إدخال هذه الطبقة شفافًا حتى لا يؤثر على التفاعل بين العميل والخادم.

5. واجهة / وحدة التحكمtract

هذه هي التقنية الأساسية التي ينبغي أن تعمل بها خدمات الويب RESTful. تعتمد RESTful بشكل أساسي على طبقة HTTP وتستخدم الأفعال الرئيسية المذكورة أدناه للتعامل مع الموارد على الخادم.

• POST – لإنشاء مورد على الخادم.
• GET – لاسترداد مورد من الخادم.
• PUT – لتغيير حالة مورد أو تحديثه.
• حذف – لإزالة أو حذف مورد من الخادم.

الراحة مقابل الصابون: الاختلافات الرئيسية

كثيرًا ما يقارن المطورون بين REST وSOAP عند تصميم خدمة ويب. يسمح كلاهما للتطبيقات الموزعة بالتواصل، لكنهما يختلفان اختلافًا كبيرًا في فلسفتهما. REST هو نمط معماري يستخدم أفعال HTTP بسيطة وتنسيقات خفيفة الوزن مثل JSON، بينما صابون هو بروتوكول صارم يعتمد على مغلفات XML واتفاقية رسميةtracيلخص الجدول أدناه أهم الفروقات.

من الناحية العملية، يُعد REST الخيار الافتراضي لواجهات برمجة تطبيقات الويب والجوال العامة لأنه أسرع وأسهل في الاستخدام، بينما يظل SOAP مفيدًا لأنظمة المؤسسات التي تتطلب أمانًا مدمجًا وتوافقًا رسميًاtracالخبر.

قم بإنشاء أول خدمة ويب مريحة في ASP.NET

الآن، في هذا البرنامج التعليمي لواجهة برمجة تطبيقات REST، سنتعلم كيفية إنشاء خدمة ويب RESTful في ASP.NET.

يمكن إنشاء خدمات الويب بلغات متنوعة، ويمكن استخدام العديد من بيئات التطوير المتكاملة لإنشاء خدمات قائمة على REST.

في هذا المثال لواجهة برمجة تطبيقات RESTful، سنقوم بإنشاء تطبيق REST الخاص بنا في بيئة .NET باستخدام Visual Studio. سنستخدم خدمة ويب RESTful لمعالجة مجموعة البيانات الموضحة أدناه.

تمثل مجموعة البيانات أدناه مثالاً على واجهة برمجة تطبيقات REST لشركة تعرض الدروس التعليمية التي لديها بناءً على معرف البرنامج التعليمي (Tutorialid).

في مثالنا التعليمي لواجهة برمجة تطبيقات REST، سنقوم بتنفيذ أفعال RESTful الموضحة أدناه.

1. الحصول على البرنامج التعليمي – عندما يقوم العميل باستدعاء واجهة برمجة التطبيقات RESTful هذه، سيتم تزويده بمجموعة كاملة من البرامج التعليمية المتاحة من خدمة الويب.
2. الحصول على البرنامج التعليمي/البرنامج التعليمي – عندما يقوم العميل باستدعاء واجهة برمجة التطبيقات RESTful هذه، سيتم منحه اسم البرنامج التعليمي بناءً على معرف البرنامج التعليمي الذي أرسله العميل.
3. ما بعد البرنامج التعليمي/اسم البرنامج التعليمي – عندما يستدعي العميل واجهة برمجة التطبيقات RESTful هذه، سيرسل طلبًا لإدراج اسم البرنامج التعليمي. ثم ستضيف خدمة الويب اسم البرنامج التعليمي المُرسل إلى المجموعة.
4. حذف البرنامج التعليمي/البرنامج التعليمي عندما يستدعي العميل واجهة برمجة التطبيقات RESTful هذه، سيرسل طلبًا لحذف اسم البرنامج التعليمي بناءً على معرّف البرنامج التعليمي. ستقوم خدمة الويب بعد ذلك بحذف اسم البرنامج التعليمي المُرسل من المجموعة.

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

كيفية إنشاء أول خدمة ويب مريحة لك

الخطوة 1) إنشاء مشروع جديد.
الخطوة الأولى هي إنشاء فارغة أسب.نت تطبيق ويب. من Visual Studio 2013، انقر على خيار القائمة ملف -> مشروع جديد.

بمجرد النقر على خيار "مشروع جديد"، سيُظهر لك برنامج Visual Studio مربع حوار آخر لاختيار نوع المشروع وإدخال التفاصيل اللازمة. سيتم شرح ذلك في الخطوة التالية.

الخطوة 2) أدخل اسم المشروع وموقعه.

1. تأكد من اختيارك أولاً C# قالب ويب لتطبيق ASP.NET. يجب أن يكون المشروع من هذا النوع لإنشاء مشروع خدمات ويب. باختيار هذا الخيار، سيقوم Visual Studio بتنفيذ الخطوات اللازمة لإضافة الملفات المطلوبة لأي تطبيق ويب.
2. أعط اسمًا لمشروعك، وهو في حالتنا "Webservice.REST".
3. ثم تأكد من تحديد موقع تخزين ملفات المشروع.

بمجرد الانتهاء، سترى ملف المشروع الذي تم إنشاؤه في مستكشف الحلول في Visual Studio 2013.

الخطوة 3) قم بإنشاء ملف خدمة الويب.
الخطوة التالية هي إنشاء ملف خدمة الويب الذي سيحتوي على خدمة الويب RESTful.

1. أولاً، انقر بزر الماوس الأيمن على ملف المشروع كما هو موضح أدناه.

2. في هذه الخطوة،
   1. انقر بزر الماوس الأيمن على ملف المشروع.
   2. اختر الخيار "إضافة -> عنصر جديد".

في مربع الحوار الذي يظهر، عليك القيام بما يلي.

1. اختر خيار خدمة WCF (مُمكّنة بتقنية Ajax). سيؤدي اختيار ملف من هذا النوع إلى إضافة Visual Studio لبعض التعليمات البرمجية الأساسية التي تساعدك في إنشاء خدمة ويب RESTful. WCF اختصار لـ Windows التواصل FoundationWCF هي مكتبة تُمكّن التطبيقات من مختلف المنصات (أو حتى نفس المنصة) من التواصل عبر بروتوكولات متنوعة مثل TCP وHTTP وHTTPS. أما Ajax فهو بروتوكول غير متزامن. Javaسيناريو ويتيح AJAX تحديث صفحات الويب بشكل غير متزامن من خلال تبادل كميات صغيرة من البيانات مع الخادم خلف الكواليس.
2. بعد ذلك، قم بإعطاء اسم للخدمة، وهو TutorialService في حالتنا.
3. وأخيرًا، انقر فوق الزر "إضافة" لإضافة الخدمة إلى الحل.

الخطوة 4) قم بإجراء التكوين.
الخطوة التالية هي إجراء تغيير في الإعدادات لتمكين هذا المشروع من العمل مع خدمات الويب RESTful. يتطلب ذلك تغييرًا في الملف المسمى Web.configيظهر هذا الملف في نفس نافذة ملف مشروع خدمة الويب. يحتوي ملف Web.config على جميع الإعدادات اللازمة لتشغيل تطبيق الويب بالشكل المطلوب. يسمح التغيير المُجرى للتطبيق بإرسال واستقبال البيانات كخدمة ويب RESTful خالصة.

1. انقر على ملف Web.config لفتح الكود.

2. ابحث عن الخط .

3. غيّر السطر إلى .

الخطوة 5) أضف الكود الخاص بنا للتنفيذ.
الخطوة التالية هي إضافة الكود الخاص بنا للتنفيذ. يجب كتابة جميع الأكواد أدناه في ملف TutorialService.svc.

1. الخطوة الأولى هي إضافة كود لتمثيل بياناتنا، والتي ستُستخدم في برنامجنا. لذا، سنُنشئ قائمة بمتغيرات نصية بقيم "Arrays" و"Queues" و"Stacks". ستُمثل هذه القائمة أسماء الدروس التعليمية المُتاحة عبر خدمة استضافة الويب الخاصة بنا.

namespace Webservice.REST
{
[ServiceContract(Namespace = "")]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class TutorialService
{
private static List<String> lst = new List<String>
(new String[] {"Arrays","Queues","Stacks"});

الخطوة 6) حدد الكود الخاص بطريقة GET الخاصة بنا.
بعد ذلك، سنحدد شيفرة دالة GET الخاصة بنا. ستُوضع هذه الشيفرة أيضًا في ملف TutorialService.svc نفسه. سيتم تشغيل هذه الشيفرة كلما استدعينا الخدمة من متصفحنا.

سيتم استخدام الطريقة التالية لتحقيق السيناريو الموضح أدناه.

• إذا أراد المستخدم قائمة بجميع الدروس التعليمية المتاحة، فسيتعين كتابة الكود أدناه لتحقيق ذلك.

[WebGet(UriTemplate = "/Tutorial")]

public String GetAllTutorial()
{
    int count = lst.Count;
    String TutorialList = "";
    for (int i = 0; i < count; i++)
        TutorialList = TutorialList + lst[i] + ",";
    return TutorialList;
}

Code تفسير:-

1. يُعد السطر الأول من التعليمات البرمجية هو الأهم. فهو يُستخدم لتحديد كيفية استدعاء هذه الطريقة عبر URLلذا، إذا كان الرابط إلى خدمة الويب الخاصة بنا هو http://localhost:52645/TutorialService.svc ونضيف '/Tutorial' إلى URL، كما في http://localhost:52645/TutorialService.svc/Tutorialسيتم استدعاء الكود المذكور أعلاه. السمة 'WebGet' هي مُعامل يسمح بأن تكون هذه الطريقة طريقة RESTful بحيث يمكن استدعاؤها عبر فعل GET.
2. يُستخدم هذا القسم من التعليمات البرمجية لتصفح قائمة السلاسل الموجودة في المتغير "lst" وإعادتها جميعًا إلى برنامج الاستدعاء.

الخطوة 7) إرجاع الإخراج.
يضمن الكود أدناه أنه في حالة إجراء استدعاء GET إلى خدمة Tutorial باستخدام معرف Tutorial، فإنه سيعيد اسم البرنامج التعليمي المقابل بناءً على معرف Tutorial.

[WebGet(UriTemplate = "/Tutorial/{Tutorialid}")]

public String GetTutorialbyID(String Tutorialid)
{
    int pid;
    Int32.TryParse(Tutorialid, out pid);
    return lst[pid];
}

Code تفسير:-

1. يُعد السطر الأول من التعليمات البرمجية هو الأهم. فهو يُحدد كيفية استدعاء هذه الطريقة عبر URLلذا، إذا كان الرابط إلى خدمة الويب الخاصة بنا هو http://localhost:52645/TutorialService.svc ونضيف '/Tutorial/{Tutorialid}' إلى URL، سنتمكن من استدعاء خدمة الويب كـ http://localhost:52645/TutorialService.svc/Tutorial/1على سبيل المثال، ستُعيد خدمة الويب اسم البرنامج التعليمي الذي يحمل معرّف البرنامج التعليمي 1.
2. يُستخدم هذا الجزء من التعليمات البرمجية لإرجاع اسم البرنامج التعليمي الذي يحتوي على معرف البرنامج التعليمي الذي تم تمريره إلى طريقة الويب.

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

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

[WebInvoke(Method = "POST", RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped,
UriTemplate = "/Tutorial/{str}")]

public void AddTutorial(String str)
{
    lst.Add(str);
}

Code تفسير:-

1. السطر الأول هو الخاصية 'WebInvoke'، المُلحقة بالدالة. تسمح هذه الخاصية باستدعاء الدالة عبر طلب POST. يجب تحديد خاصيتي RequestFormat و ResponseFormat بصيغة JSON، لأنه عند إرسال القيم إلى خدمة ويب RESTful، يجب أن تكون القيم بهذا التنسيق.
2. يُستخدم السطر الثاني من التعليمات البرمجية لإضافة قيمة السلسلة التي تم تمريرها عبر استدعاء POST إلى قائمتنا الحالية من سلاسل الدروس التعليمية.

الخطوة 9) أضف طريقة للتعامل مع عملية الحذف.
وأخيرًا، سنضيف دالتنا الخاصة للتعامل مع عملية الحذف. سيتم استدعاء هذه الدالة كلما أردنا حذف قيمة نصية موجودة من قائمة الدروس التعليمية باستخدام دالة الحذف.

[WebInvoke(Method = "DELETE", RequestFormat = WebMessageFormat.Json,
UriTemplate = "/Tutorial/{Tutorialid}", ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Wrapped)]

public void DeleteTutorial(String Tutorialid)
{
    int pid;
    Int32.TryParse(Tutorialid, out pid);
    lst.RemoveAt(pid);
}

Code تفسير:-

1. السطر الأول هو الخاصية 'WebInvoke'، المُلحقة بالدالة. يسمح هذا باستدعاء الدالة عبر أمر DELETE. يجب تحديد الخاصيتين RequestFormat و ResponseFormat بصيغة JSON، لأن القيم يجب أن تكون بهذه الصيغة. لاحظ أن مُعامل Method مُعيّن على "DELETE". هذا يعني أنه كلما استخدمنا أمر DELETE، سيتم استدعاء هذه الدالة.
2. يتم استخدام السطر الثاني من التعليمات البرمجية للحصول على البرنامج التعليمي الذي تم إرساله عبر استدعاء DELETE ومن ثم حذف هذا المعرف من قائمتنا. (ال Int32 تُستخدم الدالة الموجودة في الكود لتحويل معرّف البرنامج التعليمي من متغير نصي إلى عدد صحيح.

تشغيل أول خدمة ويب مريحة

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

لتشغيل خدمة الويب، يرجى اتباع الخطوات التالية.

الخطوة 1) انقر بزر الماوس الأيمن على ملف المشروع – Webservice.REST.

الخطوة 2) اختر خيار القائمة "تعيين كمشروع بدء التشغيل". سيضمن هذا تشغيل هذا المشروع عند تشغيل Visual Studio للحل بأكمله.

الخطوة 3) الخطوة التالية هي تشغيل المشروع نفسه. بناءً على المتصفح الافتراضي المُثبّت على النظام، سيظهر اسم المتصفح المناسب بجوار زر التشغيل في Visual Studio. في حالتنا، لدينا Google Chrome تظهر. فقط انقر على هذا الزر.

انتاج:-

عند تشغيل المشروع، يمكنك الانتقال إلى قسم TutorialService.svc/Tutorial، وستحصل على المخرجات أدناه.

في المخرجات أعلاه،

• يمكنك ملاحظة أن المتصفح يستدعي فعل "GET" وينفذ دالة "GetAllTutorial" في خدمة الويب. تُستخدم هذه الوحدة لعرض جميع الدروس التعليمية التي توفرها خدمة الويب الخاصة بنا.

اختبار أول خدمة ويب مريحة

في القسم أعلاه، رأينا بالفعل كيفية استخدام المتصفح لتنفيذ فعل "GET" واستدعاء "GetAllTutorial".

1. فلنستخدم الآن المتصفح لتنفيذ سيناريو حالة الاستخدام التالي.

GET Tutorial/Tutorialid – عندما يقوم العميل باستدعاء واجهة برمجة التطبيقات RESTful هذه، سيتم منحه اسم البرنامج التعليمي بناءً على Tutorialid الذي أرسله العميل.

في متصفحك، أضف السلسلة /1 بعد كلمة Tutorial في URLإذا ضغطت على زر الإدخال، فستحصل على الناتج أدناه.

سترى الآن ناتج "Queues"، الذي يُطابق الرقم 1 في قائمة سلاسل الدروس التعليمية. هذا يعني أنه يتم استدعاء دالة "GetTutorialbyID" من خدمة الويب الخاصة بنا. كما يُظهر أن القيمة 1 تُمرر بنجاح عبر المتصفح إلى خدمة الويب وإلى الدالة، ولذلك نحصل على القيمة الصحيحة لـ "Queues" في المتصفح.

2. بعد ذلك، لنستخدم خدمة الويب الخاصة بنا من خلال تنفيذ السيناريو أدناه. للقيام بذلك، ستحتاج إلى تثبيت الأداة المسماة Fiddlerوهي أداة مجانية قابلة للتنزيل.

POST Tutorial/Tutorialname – عندما يستدعي العميل واجهة برمجة التطبيقات RESTful هذه، سيرسل طلبًا لإدراج اسم البرنامج التعليمي. ثم ستضيف خدمة الويب اسم البرنامج التعليمي المُرسل إلى المجموعة.

تشغيل Fiddler استخدم الأداة وقم بتنفيذ الخطوات التالية.

1. انتقل إلى قسم المُنشئ. يُستخدم هذا القسم لإنشاء طلبات يمكن إرسالها إلى أي تطبيق ويب.
2. تأكد من أن نوع الطلب هو "POST" والصحيح URL يتعرض للضرب، وهو ما ينبغي أن يكون عليه الحال في حالتنا http://localhost:52645/TutorialService.svc/Tutorial.
3. تأكد من تحديد نوع المحتوى كـ application/json. تذكر أن طريقة طلب POST في خدمة الويب لدينا تقبل بيانات بتنسيق JSON فقط، لذا يجب التأكد من تحديد ذلك عند إرسال طلب إلى تطبيقنا.
4. أخيرًا، نحتاج إلى إدخال بياناتنا. تذكر أن دالة POST تقبل مُعاملًا يُسمى 'str'. لذا، نُحدد هنا أننا نريد إضافة قيمة تُسمى "Trees" إلى مجموعة أسماء الدروس التعليمية، ونتأكد من ربطها باسم المتغير 'str'.

وأخيرًا، انقر فوق زر التنفيذ في Fiddlerسيؤدي هذا إلى إرسال طلب إلى خدمة الويب لإرسال بيانات "الأشجار" إلى خدمة الويب الخاصة بنا.

الآن، عندما نتصفح إلى البرنامج التعليمي URL لعرض جميع النصوص في قائمة الدروس التعليمية، ستلاحظ وجود قيمة "Trees" أيضًا. هذا يدل على أن طلب POST إلى خدمة الويب قد نُفِّذ بنجاح، وأنه قد أُضيف بنجاح إلى قائمة الدروس التعليمية.

3. بعد ذلك، دعونا نستهلك خدمة الويب الخاصة بنا من خلال تنفيذ السيناريو أدناه. لهذا، نحتاج أيضًا إلى استخدام Fiddler الأداة.

حذف البرنامج التعليمي/معرف البرنامج التعليمي - عندما يستدعي العميل واجهة برمجة التطبيقات RESTful هذه، سيرسل طلبًا لحذف اسم البرنامج التعليمي بناءً على معرف البرنامج التعليمي. ستقوم خدمة الويب بعد ذلك بحذف اسم البرنامج التعليمي المُرسل من المجموعة.

تشغيل Fiddler استخدم الأداة وقم بتنفيذ الخطوات التالية.

1. انتقل إلى قسم المُنشئ. يُستخدم هذا القسم لإنشاء طلبات يمكن إرسالها إلى أي تطبيق ويب.
2. تأكد من أن نوع الطلب هو "حذف" وأنّه صحيح URL يتعرض للضرب، وهو ما ينبغي أن يكون عليه الحال في حالتنا http://localhost:52645/TutorialService.svc/Tutorialتأكد من إرسال المعرّف المستخدم لحذف سلسلة نصية من القائمة عبر URL كمعامل. في مثال REST الخاص بنا، نرسل 1، لذا سيؤدي هذا إلى حذف 2^nd عنصر في مجموعتنا، وهو "الصفوف".

وأخيرًا، انقر فوق زر التنفيذ في Fiddlerسيؤدي هذا إلى إرسال طلب إلى خدمة الويب لحذف بيانات "قوائم الانتظار" من خدمة الويب الخاصة بنا.

الآن، عندما نتصفح إلى البرنامج التعليمي URL لعرض جميع السلاسل في قائمة البرنامج التعليمي لدينا، ستلاحظ أن قيمة "Queues" لم تعد موجودة.

هذا يدل على أن طلب الحذف إلى خدمة الويب قد نُفِّذ بنجاح. تم حذف العنصر الموجود في الفهرس رقم 1 في قائمة سلاسل الدروس التعليمية بنجاح.

RESTful API أفضل الممارسات

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

• استخدم الأسماء، وليس الأفعال، في URLs. نقاط النهاية مثل /الموظفون/1 أوضح من /getEmployee?id=1لأن فعل HTTP يصف الإجراء بالفعل.
• أعد رموز الحالة ذات الدلالة. أرسل 200 للنجاح، 201 لمورد تم إنشاؤه، 400 لطلب غير صالح، 401 للوصول غير المصرح به، 404 لمورد مفقود، و500 لأخطاء الخادم.
• قم بإصدار نسخة من واجهة برمجة التطبيقات الخاصة بك. إضافة قسم الإصدار مثل /v1/ يتيح لك المسار تطوير الخدمة دون الإضرار بالعملاء الحاليين.
• قم بتأمين كل نقطة نهاية. استخدم بروتوكول HTTPS، بالإضافة إلى مفاتيح API أو رموز OAuth 2.0، وقم بالتحقق من صحة جميع المدخلات الواردة.
• يدعم ترقيم الصفحات والتصفية. يؤدي إرجاع مجموعات كبيرة في صفحات إلى الحفاظ على سرعة الاستجابات وتقليل حمل الخادم.

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

الأسئلة الشائعة