سؤال

أنا أبحث عن بعض الروابط الجيدة مع أفضل الممارسات ونموذج التعليمات البرمجية حول الإنشاء استراحةخدمات الويب الكاملة باستخدام .NET.

وأيضًا، أي مدخلات أخرى قد تكون لديك بخصوص REST ستكون موضع تقدير كبير.

هل كانت مفيدة؟

المحلول

خدمات بيانات ADO.Net يجعل من السهل حقا بناء و تستهلك خدمات الويب RESTful في عالم .Net ولكن مع ذلك فإن فهم المفاهيم أمر مهم.مقارنةً بـ WCF (الذي أضاف دعم REST لاحقًا)، تم إنشاء ADO.Net Data Services بشكل أساسي لـ REST.

إرشادات لبناء خدمات ويب RESTful لديه كل المعلومات عن الموارد التي تحتاج إليها.

وهذا مفيد آخر دخول بلوق:

تصف قيود الواجهة الموحدة كيف يمكن لخدمة مصممة للويب أن تكون مشاركًا جيدًا في بنية الويب.ويتم وصف هذه القيود بإيجاز على النحو التالي:

1) تحديد الموارد:المورد هو أي عنصر معلومات يمكن تسميته وتمثيله (على سبيل المثال:مستند، وسعر السهم في وقت معين، والطقس الحالي في لاس فيغاس، وما إلى ذلك).يجب تحديد الموارد في خدمتك باستخدام عناوين URI.

2) التلاعب بالموارد عبر التمثيلات:التمثيل هو التمثيل المادي للمورد ويجب أن يتوافق مع نوع وسائط صالح.يؤدي استخدام أنواع الوسائط القياسية كتنسيقات البيانات خلف خدمتك إلى زيادة مدى وصول خدمتك من خلال جعلها في متناول مجموعة واسعة من العملاء المحتملين.يجب أن يعتمد التفاعل مع المورد على استرجاع ومعالجة تمثيل المورد المحدد بواسطة URI الخاص به.

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

4) الوسائط التشعبية كمحرك لحالة التطبيق:يجب التعبير عن حالة التطبيق باستخدام عناوين URI والارتباطات التشعبية للانتقال بين الحالات.ربما يكون هذا هو الأكثر إثارة للجدل والأقل فهمًا للقيود المعمارية المنصوص عليها في أطروحة روي فيلدنج.في الواقع، تحتوي أطروحة فيلدينغ على حجج صريحة ضد استخدام ملفات تعريف الارتباط HTTP لتمثيل حالة التطبيق لتوضيح هذه النقطة، ومع ذلك يتم تجاهلها غالبًا.

نصائح أخرى

مؤسسة ويندوز للاتصالات يدعم نموذج REST منذ .NET 3.5.

يمكنك العثور على الوثائق ونماذج التعليمات البرمجية على MSDN:

الراحة والجدري

بعض الموارد لتعلم REST:

أفضل مقدمة قرأتها هي كتاب RESTful لخدمات الويب, ، والذي يتجاوز مجرد شرح النموذج والمبادئ ويوضح لك في الواقع كيفية تصميم خدمة ويب RESTful.الأكثر فائدة هي قائمة التحقق الخاصة بها لكيفية كتابة/تحديد REST API:

  1. اكتشف مجموعة البيانات [أيحدد نموذج البيانات].
  2. تقسيم مجموعة البيانات إلى موارد.لكل نوع من الموارد:
  3. قم بتسمية الموارد باستخدام عناوين URI.
  4. كشف مجموعة فرعية من الواجهة الموحدة [أيحدد طرق HTTP المستخدمة وماذا يفعلون].
  5. تصميم الإقرارات (الإقرارات) المقبولة من العميل [على سبيل المثال:تنسيق XML الذي يمكنك وضعه أو نشره].
  6. تصميم التمثيلات (التمثيلات) المقدمة للعميل [على سبيل المثال.XML الذي تستعيده].
  7. قم بدمج هذا المورد في الموارد الموجودة، باستخدام روابط ونماذج الوسائط التشعبية.
  8. النظر في المسار النموذجي للأحداث:ما الذي من المفترض أن يحدث؟[يشبه هذا سيناريو النجاح الرئيسي لحالة الاستخدام.]
  9. النظر في شروط الخطأ.[هذا يشبه سيناريوهات استثناء حالة الاستخدام.]

المقالات من "ويب مريح"المسلسل في xml.com هي مقدمة رائعة.

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

عندما بدأت في تطوير خدمات الويب REST، قرأت كتاب قواعد تصميم REST API من Mark Masse.بمجرد أن تعرف الأساسيات والنظرية، ستتمكن من تنفيذ REST باستخدام WCF أو HTTPListener أو ServiceStack.جميع هذه الأطر هي .NET وموثقة بشكل جيد...

أوصي بمكدس الخدمة (http://www.servicestack.net/) حيث توجد معلومات كافية على الويب للبدء.

يقدم WCF واجهة برمجة تطبيقات الويب ASP.NET، وهو أمر جيد، لكنني لا أستخدمه.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top