एक विश्वसनीय कॉल में सर्वर पर राज्य को अद्यतन करने के लिए HTTP GET का उपयोग क्यों गलत है?

Question

ठीक है, मैं पहले से ही कागज पर सभी कारणों कारण है कि मैं उपयोग नहीं करना चाहिए पता है एक HTTP GET जब सर्वर पर कुछ की स्थिति को अद्यतन करने के एक RESTful कॉल कर। इस प्रकार हर बार संभावित रूप से अलग डेटा लौट रहा है। और मुझे पता है इस कारण 'कागज पर' निम्नलिखित के लिए गलत है:

• HTTP GET कॉल
• एन idempotent किया जाना चाहिए> 0 कॉल हमेशा एक ही डेटा वापस
• का उल्लंघन HTTP कल्पना मिलना चाहिए
• HTTP GET कॉल आमतौर पर केवल पढ़ने के लिए

और मुझे यकीन है कि और भी कारण हैं। लेकिन मुझे "ठीक है, जो HTTP स्पेक का उल्लंघन करता है" के अलावा औचित्य के लिए एक ठोस सरल उदाहरण की आवश्यकता है। ... या कम से कम मैं एक के लिए उम्मीद कर रहा हूँ। मैं भी पहले से ही जिसके बाद सूची की तर्ज ऊपर के साथ और अधिक कर रहे हैं पढ़ा है: Does it violate the RESTful when I write stuff to the server on a GET call? & HTTP POST with URL query parameters -- good idea or not?

उदाहरण के लिए, किसी को ऊपर सही साबित कर सकते हैं और क्यों यह गलत/खराब व्यवहार का/गलत उपयोग करने के लिए एक HTTP GET है कहते हैं निम्नलिखित RESTful कॉल

"MyRESTService/GetCurrentRecords?UpdateRecordID=5&AddToTotalAmount=10" 

साथ मैं जानता हूँ कि यह गलत है, लेकिन उम्मीद है कि यह मदद मिलेगी अपने मूल सवाल का जवाब देने के लिए एक उदाहरण प्रदान करते हैं। तो उपरोक्त AddToTotalAmount = 10 के साथ recordID = 5 अपडेट करेगा और फिर अद्यतन रिकॉर्ड लौटाएगा। मुझे पता है कि एक पोस्ट का उपयोग किया जाना चाहिए, लेकिन मान लें कि मैंने एक जीईटी का उपयोग किया है।

कैसे बिल्कुल और मेरे प्रश्न का उत्तर देने के लिए या यह वास्तविक समस्या का कारण बन सकता है? उपरोक्त बुलेट सूची के सभी उल्लंघनों के अलावा, उपरोक्त करने के लिए HTTP GET का उपयोग कैसे कर सकते हैं कुछ वास्तविक समस्या? कई बार मैं एक ऐसे परिदृश्य में आ जाता हूं जहां मैं चीजों को औचित्य दे सकता हूं "क्योंकि डॉक्टर ने ऐसा कहा था", लेकिन मुझे इस पर औचित्य और बेहतर समझ की आवश्यकता है।

धन्यवाद!

Answer 1

व्यावहारिक मामला जहां आपको कोई समस्या होगी, HTTP HTTP को अक्सर HTTP कार्यान्वयन की विफलता की स्थिति में पुनः प्रयास किया जाता है। तो आप वास्तविक जीवन में स्थितियों को प्राप्त कर सकते हैं जहां एक ही जीईटी सर्वर द्वारा कई बार प्राप्त किया जाता है। यदि आपका अपडेट बेवकूफ है (जो आपका है), तो कोई समस्या नहीं होगी, लेकिन अगर यह बेवकूफ नहीं है (उदाहरण के लिए राशि में कुछ मूल्य जोड़ना), तो आप एकाधिक (अवांछित) अपडेट प्राप्त कर सकते हैं।

HTTP पोस्ट कभी भी पुनः प्रयास नहीं किया जाता है, इसलिए आपको कभी भी यह समस्या नहीं होगी।

Answer 2

मुझे लगता है कि इस संसाधन को पढ़ना: http://www.servicedesignpatterns.com/WebServiceAPIStyles संदेश API और संसाधन एपीआई के बीच अंतर बनाने में आपकी मददगार हो सकता है?

Answer 3

यदि खोज इंजन के कुछ प्रकार आपकी साइट स्पाइडर हैं तो यह आपके डेटा को अनजाने में बदल सकता है।

यह अतीत में Google की डेस्कटॉप खोज के साथ हुआ जिससे लोगों ने डेटा खो दिया क्योंकि लोगों ने जीईटी के रूप में हटाए गए कार्यों को लागू किया था।

Answer 4

यहां एक महत्वपूर्ण कारण है कि जीईटी बेवकूफ होना चाहिए और क्रॉस साइट अनुरोध फोर्जरी अटैक के संबंध में सर्वर पर राज्य को अद्यतन करने के लिए उपयोग नहीं किया जाना चाहिए। पुस्तक से: Professional ASP.NET MVC 3

idempotent हो जाता है
बिग शब्द, सुनिश्चित करें के लिए - लेकिन यह एक सरल अवधारणा है। यदि ऑपरेशन बेवकूफ है, तो परिणाम को बदलकर के बिना इसे कई बार निष्पादित किया जा सकता है। आम तौर पर, अंगूठे का एक अच्छा नियम यह है कि आप सीएसआरएफ हमलों की पूरी कक्षा को केवल डीबी या POST का उपयोग कर अपनी साइट पर बदलकर चीजों को बदलकर रोक सकते हैं। इसका मतलब है पंजीकरण, लॉगआउट, लॉगिन, और बहुत आगे। कम से कम, यह उलझन में डिप्टी हमलों को सीमित करता है।