سؤال

ما هو الحد الأدنى لمجموعة أفعال HTTP التي يجب أن يسمح بها الخادم لتصنيف خدمة الويب على أنها RESTful؟

ماذا لو لم يسمح مضيفي بذلك يضع و يمسح?

هل هذا مهم حقًا، هل يمكنني أن أعيش في سعادة دائمة مع فقط يحصل و بريد ?


تحديث: شكرا على الإجابات يا جماعة إجابة روجر ربما كان الأفضل بسبب الارتباط بمقابلة بيل فينيرز وإليوت رستي هارولد.لقد فهمت الآن.


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

المحلول

نعم، يمكنك العيش بدون PUT وDELETE.

يخبرك هذا المقال لماذا:http://www.artima.com/lejava/articles/why_put_and_delete.html

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

روبية

نصائح أخرى

يمكنك أيضًا استخدام X-Http-Verb-Override:DELETE inst.من حذف HTTP.يعد هذا مفيدًا أيضًا لعملاء Silverlight الذين لا يستطيعون تغيير أفعال HTTP ويدعمون فقط GET وPOST...

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

يسمح REST بكسر اتفاقية البروتوكول في حالة تعطل تطبيقات البروتوكول (بحيث تكون الأشياء غير القياسية الوحيدة التي تفعلها هي الالتفاف حول الأجزاء المعطلة من التنفيذ).لذا فمن المسموح به داخل REST استخدام طريقة أخرى لتمثيل الأفعال غير المدعومة بشكل عام مثل DELETE أو PUT.

يحرر:فيما يلي اقتباس من فيلدينغ، وهو الذي أنشأ وحدد REST:

يجب ألا تحتوي واجهة REST API على أي تغييرات في بروتوكولات الاتصال بخلاف ملء أو إصلاح تفاصيل البتات غير المحددة من البروتوكولات القياسية، مثل طريقة PATCH الخاصة بـ HTTP أو حقل رأس الارتباط.يجب تحديد الحلول البديلة للتطبيقات المعطلة (مثل تلك المتصفحات الغبية بما يكفي للاعتقاد بأن HTML تحدد مجموعة أساليب HTTP) بشكل منفصل، أو على الأقل في الملاحق، مع توقع أن الحل البديل سيصبح قديمًا في النهاية.[يشير الفشل هنا إلى أن واجهات الموارد خاصة بالكائنات، وليست عامة.]

متصفحات الويب اليوم تتعامل فقط مع GETS + POSTS.في Rails، على سبيل المثال، يتم "تزوير" PUTS + DELETES من خلال حقول النموذج المخفية.

ما لم يكن لدى إطار العمل الخاص بك بعض الحلول البديلة "لدعم" PUTS + DELETES، فلا تقلق بشأنها في الوقت الحالي.

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