मुझे गैर-भरोसेमंद डिज़ाइन का उदाहरण दें?

Question

मैंने रेल डेवलपर के रूप में "रीस्टफुल" शब्द सीखा। विकिपीडिया पढ़ने के बाद, here और here भी पढ़ें।

मुझे यह नहीं मिला। ऐसा लगता है कि रेल यूआरएल का वर्णन करने के लिए केवल संक्षिप्त का उपयोग कर रहा है। ऐसा लगता है कि हर यूआरआई रीस्टफुल है, इसमें स्कोप डिज़ाइन किया गया है।

उदाहरण के लिए, मुझे लगता है कि GET /delete?student_id=3 रीस्टफुल दायरे में एप्लिकेशन है।

क्या कोई मुझे बता सकता है कि यह किस उल्लंघन का उल्लंघन करता है? कृपया REST definition से कंक्रीट देखें।

Answer 1

ए GET अनुरोध idempotent होना चाहिए और अनुरोध सर्वर पर किसी भी दुष्प्रभाव को नहीं छोड़ना चाहिए। HTTP spec sec 9.1.1 से हवाला देते हुए:

विशेष रूप से, सम्मेलन स्थापित किया गया है कि GET और HEAD तरीकों पुनः प्राप्ति के अलावा किसी अन्य कार्रवाई करने के महत्व को नहीं होना चाहिए। इन तरीकों को "सुरक्षित" माना जाना चाहिए। यह उपयोगकर्ता एजेंटों को अन्य तरीकों का प्रतिनिधित्व करने की अनुमति देता है, जैसे कि POST, PUT और DELETE, विशेष रूप से, ताकि उपयोगकर्ता को इस तथ्य से अवगत कराया जा सके कि संभावित रूप से असुरक्षित कार्रवाई का अनुरोध किया जा रहा है।

इसलिए GET /delete?student_id=3 पहले से ही, GET क्रिया के idempotency धारणा का उल्लंघन करता है, क्योंकि यह सर्वर पर एक रिकॉर्ड को नष्ट करेगा।

एक विश्वसनीय इंटरफ़ेस एक समान इंटरफ़ेस है, जो दूसरे शब्दों में है कि GET को HTTP spec द्वारा आवश्यक व्यवहार करना चाहिए।

GET विधि का मतलब है पुनः प्राप्त जो भी जानकारी (एक इकाई के रूप में) अनुरोध- URI द्वारा पहचाना जाता है: और यह क्या the spec says है। यदि अनुरोध-यूआरआई को डेटा-उत्पादक प्रक्रिया में संदर्भित करता है, तो यह उत्पादित डेटा है जो प्रतिक्रिया में इकाई के रूप में लौटाया जाएगा और प्रक्रिया का स्रोत टेक्स्ट नहीं, जब तक कि पाठ का उत्पादन न हो प्रक्रिया।

...

Answer 2

एक प्राप्त RESTful होने के लिए सुरक्षित है, लेकिन एक को हटाने के साथ यह असुरक्षित है स्पष्ट रूप से संयुक्त होना चाहिए।

तो यह रीस्टफुल लगता है लेकिन रीस्टफुल नहीं करता है। तो यह duck test विफल रहता है।

Answer 3

ऐसा लगता है कि रेल केवल यूआरएल का वर्णन करने के लिए संक्षिप्त तरीका का उपयोग कर रहा है। ऐसा लगता है कि मेरे लिए हर यूआरआई रीस्टफुल है, इसमें डिज़ाइन किया गया है।

यूआरआई न तो भरोसेमंद या गैर-भरोसेमंद हैं। आरईएसटी एक वास्तुशिल्प शैली है जिसके लिए आपको समग्र आवेदन पर विचार करने की आवश्यकता है।

GET पुनर्प्राप्ति अनुरोध के लिए विधि है। यदि आप इसे आरईएसटी शोध प्रबंध के संदर्भ में रखना चाहते हैं, यदि आपके GET अनुरोध के दुष्प्रभाव हैं, तो यह कुछ अन्य बाधाओं को तोड़ देगा, उदाहरण के लिए कैश के संबंध में।

आप संभावित रूप से एक रीस्टफुल सिस्टम भी डिज़ाइन कर सकते हैं जहां GET /delete?student_id=3 अनुरोध आपको एक प्रतिनिधित्व देता है (या आपको पुष्टि करने के लिए कहता है) कि आप उस छात्र को हटाना चाहते हैं, जब तक कि यह वास्तव में डिलीट ऑपरेशन नहीं करता है।

Answer 4

अनुभाग 5.1.5 देखें। आपका उदाहरण वर्दी इंटरफ़ेस बाधा का उल्लंघन करता है। यह HTTP spec का उल्लंघन करके ऐसा करता है।