मैं एक आरईएसटी सेवा (विंडोज सीई प्लेटफॉर्म पर यदि मायने रखता है) को लागू करने में अच्छी तरह से हूं और मैंने अद्यतन करने के लिए POST का उपयोग करने के लिए IBM's general definitions का उपयोग शुरू किया है।आरईएसटी क्रियाएं - कौन सा सम्मेलन "सही"
अब मैं Sun's definitions पर चला गया हूं जो बिल्कुल विपरीत है। तो मेरा सवाल है, जो "आम तौर पर स्वीकृत" परिभाषा है? या यहां तक कि एक भी है?
संसाधन बनाने के लिए PUT का उपयोग करने का नुकसान यह है कि क्लाइंट को अद्वितीय आईडी प्रदान करना है जो उस वस्तु का प्रतिनिधित्व करता है जो इसे बना रहा है। हालांकि यह अद्वितीय आईडी उत्पन्न करने के लिए क्लाइंट के लिए आमतौर पर संभव है, अधिकांश एप्लिकेशन डिज़ाइनर पसंद करते हैं कि उनके सर्वर (आमतौर पर अपने डेटाबेस के माध्यम से) इस आईडी को बनाते हैं। ज्यादातर मामलों में हम संसाधन सर्वर की पीढ़ी को नियंत्रित करने के लिए हमारे सर्वर चाहते हैं। तो हम क्या करे? हम पुट के बजाय POST का उपयोग करने के लिए स्विच कर सकते हैं।
तो: रखें = अद्यतन
पोस्ट = सम्मिलित
+1। –
हालांकि यह एक अच्छा कारण देता है कि कोई व्यक्ति सम्मिलन के लिए पोस्ट का उपयोग क्यों कर सकता है, यह वास्तव में इसे मानक के रूप में स्थापित नहीं करता है। आईडी पीढ़ी किसी भी व्यक्ति के लिए Guids का उपयोग करने में कोई समस्या नहीं है। शायद सही जवाब यह है कि कोई आम तौर पर स्वीकार्य मानक नहीं है। आप HTTP क्रियाओं का उपयोग कर सकते हैं क्योंकि आप एक सेवा को लागू करने के लिए सर्वोत्तम फिट देखते हैं जो REST सिद्धांतों का सम्मान करता है। –
हम POST = बनाएँ, PUT = अद्यतन का उपयोग करते हैं।
क्यों? अच्छा कारण नहीं है। हमें एक चुनना पड़ा, और यही वह विकल्प है जिसे मैंने बनाया था।
संपादित करें। अन्य उत्तरों को देखते हुए, मुझे एहसास हुआ कि मुख्य निर्माण समस्या निर्णय ले सकती है।
हम नई प्रविष्टियां पोस्ट करते हैं और जेनरेट की गई कुंजी के साथ एक JSON ऑब्जेक्ट वापस करते हैं। ऐसा लगता है कि आम तौर पर स्वीकृत पोस्ट अर्थशास्त्र के लिए यह एक बेहतर फिट है।
हम ऑब्जेक्ट की पहचान करने वाले पूर्ण यूआरआई के साथ मौजूदा प्रविष्टियों को डालते हैं।
असल में बस एक चुनें और उसके साथ चलाएं। मैंने जो (अनजाने में) किया - बस यह सुनिश्चित करना चाहता था कि मैं सामान्य अभ्यास के विपरीत चुनकर अपने सभी ग्राहकों को भ्रमित नहीं कर रहा था। – ctacke
"ग्राहक"? कृपया यह बताने के लिए अपना प्रश्न अपडेट करें कि कौन भ्रमित हो सकता है। –
"ग्राहक" से मेरा मतलब है कि अगर मैं अपने ग्राहक (जो काम के लिए भुगतान कर रहा है, सेवा उपभोक्ता ऐप नहीं) के लिए यह सेवा बनाते हैं, तो वे आगे बढ़ते हैं और इसे विस्तारित करना चाहते हैं और उन सेवाओं को जोड़ना चाहते हैं जो वे समाप्त नहीं होते हैं मुझे लगता है कि POST/PUT का उपयोग उन सभी चीज़ों से पिछड़ा है जो वे उदाहरण के रूप में देख रहे हैं। कुंजी निर्माण मुद्दे पर – ctacke
PUT सर्वर अनुदान जब इसकी यूआरआई अंतरिक्ष के एक हिस्से से अधिक ग्राहक नियंत्रण निर्माण के लिए इस्तेमाल किया जा सकता। यह फ़ाइल सिस्टम में फ़ाइल निर्माण के बराबर है: जब आप किसी फ़ाइल में सहेजते हैं जो अभी तक मौजूद नहीं है तो आप इसे बनाते हैं और यदि वह फ़ाइल मौजूद है तो परिणाम एक अद्यतन है।
हालांकि, PUT में ग्राहक के निहित इरादे की क्षमता की कमी है। ऑर्डर देने पर विचार करें: यदि आप/ऑर्डर/मेरे-ऑर्डर ऑर्डर करते हैं तो अर्थ केवल/ऑर्डर/मेरे-नए ऑर्डर द्वारा पहचाने गए संसाधन को अपडेट कर सकता है जबकि POST/ऑर्डर/का मतलब है 'नया ऑर्डर दें' पोस्ट स्वीकृति संसाधन में उपयुक्त अर्थशास्त्र है।
आईओयू, यदि आप नए संसाधन के निर्माण के दुष्प्रभाव के रूप में कुछ हासिल करना चाहते हैं तो आपको POST का उपयोग करना होगा।
जनवरी
कारण सम्मिलित रूप में पोस्ट उपयोग करने के लिए और अद्यतन के रूप में रखा है कि पोस्ट HTTP के अनुसार केवल nonidempotent और असुरक्षित आपरेशन है। बेवकूफ का मतलब है कि इससे कोई फर्क नहीं पड़ता कि आप कितनी बार ऑपरेशन लागू करते हैं, नतीजा हमेशा एक जैसा होता है। एसक्यूएल आईएनएसईआरटी में एकमात्र nonidempotent ऑपरेशन है इसलिए इसे POST पर मैप किया जाना चाहिए। अद्यतन बेवकूफ है इसलिए इसे PUT पर मैप किया जा सकता है। इसका मतलब है कि एक ही PUT/UPDATE ऑपरेशन एक से अधिक बार लागू किया जा सकता है लेकिन केवल पहले हमारे सिस्टम/डेटाबेस की स्थिति बदल जाएगा।
इस प्रकार आईएनएसईआरटी के लिए पीयूटी का उपयोग करने से HTTP अर्थपूर्ण viz आवश्यकता टूट जाएगी जो PUT ऑपरेशन बेवकूफ होना चाहिए।
पूरी तरह से सच नहीं है। यदि आप क्रिस्टियन बोरीयू के जवाब को देखते हैं।क्लाइंट आईडी प्रदान करते समय PUT का उपयोग करते समय, उसी आईडी के साथ दूसरा PUT एक नया निर्माण करने के बजाय नव निर्मित संसाधन को ओवरराइट करेगा। यह ऑपरेशन idempotent रखेंगे। –
यहां http://www.w3.org/Protocols/rfc2616/rfc2616.html HTTP विधियों के व्यवहार को कार्यान्वित करने का तरीका है।
Seroiusly? आपका जवाब "संपूर्ण HTTP आरएफसी पढ़ें" है? यह RESTful सेवाओं को लागू करने के लिए आज आरईएसटी या मानक सम्मेलनों के बारे में बात नहीं करता है। मैंने जिस वेब सर्वर पर चल रहा है उसे लिखा है, इसलिए मुझे पता है कि HTTP कैसे काम करता है। मैं उस सर्वर पर चल रही एक आरईएसटी सेवा को लागू करते समय सर्वोत्तम प्रथाओं का उपयोग करने की कोशिश कर रहा हूं। – ctacke
नहीं, यह समझने के लिए कि HTTP विधियां कैसे काम करती हैं आपको केवल HTTP विधियों पर भागों को पढ़ने की आवश्यकता है: -P। आरईएसटी बाधाओं में से एक, वर्दी इंटरफेस, मूल रूप से तात्पर्य है कि HTTP पर आरईएसटी करते समय आरएफसी 2616 आपका बाइबल है। हो सकता है कि आप जो खोज रहे हैं वह आरईएसटी कुकबोक है जो रीस्टफुल सिस्टम में सामान्य समस्याओं को हल करने के लिए मानक व्यंजनों का एक सेट है। Http://www.amazon.com/RESTful-Web-Services-Cookbook-Scalability/dp/0596801688/ ref = sr_1_1? यानी = यूटीएफ 8 और एस = किताबें और qid = 1268695534 और sr = 8-1 –
क्रियाएं हैं:
GET {path}: पुनः प्राप्त संसाधन जिसका पहचानकर्ता {path} है।
PUT {path}: संसाधन बनाएं जिसका अद्यतन {path} है।
DELETE {path}: हटाएं संसाधन जिसका पहचान {path} है।
POST {path}: को {path} द्वारा पहचाना गया एक क्रिया शामिल करें।
जब कोई नया संसाधन बनाना है, तो हम PUT का उपयोग कर सकते हैं यदि हम जानते हैं कि संसाधन का पहचानकर्ता क्या होना चाहिए, और हम POST का उपयोग कर सकते हैं यदि हम चाहते हैं कि सर्वर नए संसाधन के पहचानकर्ता को निर्धारित करे।
POST की आपकी परिभाषा मेरे द्वारा लिंक किए गए दोनों दस्तावेज़ों के विपरीत है। ऐसा लगता है कि एक क्रिया का उपयोग करने का संकेत मिलता है, जो मुझे विश्वास है, – ctacke
को हतोत्साहित किया गया है आप सही हैं। मेरी परिभाषा आईबीएम और सूर्य दोनों की परिभाषाओं के विपरीत है, क्योंकि आईबीएम और सूर्य दोनों को यह गलत लगता है। कृपया http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services – yfeldblum
पर नमूनों और अर्थों की तालिका देखें कृपया ध्यान दें कि 'प्राप्त करें', 'पुट' और 'DELETE' मानक हैशटेबल (जावास्क्रिप्ट ऑब्जेक्ट, रूबी हैश, पायथन dict) संचालन। हैशटेबल्स पर, ये विधियां सभी बेवकूफ हैं। इसके विपरीत, 'POST' एक हैशटेबल पर एक सरल ऑपरेशन करने के बजाय, सेवा पर एक जटिल विधि का आह्वान करने की छवि को आमंत्रित करता है। दरअसल, 'POST' सभी उपयोग मामलों के लिए है जहां तीन सरल हैशटेबल ऑपरेशंस ('GET',' PUT', और 'DELETE') अपर्याप्त हैं। – yfeldblum
मैं हाल ही में आरईएसटी की अवधारणाओं और कार्यान्वयन का अध्ययन कर रहा हूं और सामान्य आम सहमति प्रतीत होती है: PUT का उपयोग इस संसाधन के आधार पर बनाने/अपडेट करने के लिए किया जाता है कि संसाधन पहले से मौजूद है या नहीं। एक संग्रह में संसाधन जोड़ने के लिए POST का उपयोग किया जाता है।
देखें HTTP/1.1 विधि परिभाषाएँ http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
पोस्ट एक समान पद्धति का अनुसरण कार्यों को कवर करने के लिए अनुमति देने के लिए बनाया गया है:
- Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation.PUT विधि अनुरोध करता है कि संलग्न इकाई के तहत संग्रहीत किया अनुरोध-यूआरआई प्रदान किया गया। यदि अनुरोध-यूआरआई पहले से मौजूद संसाधन को संदर्भित करता है, तो संलग्न इकाई को मूल सर्वर पर रहने वाले किसी के संशोधित संस्करण के रूप में माना जाना चाहिए।
Understanding REST: Verbs, error codes, and authentication पर प्रश्न के स्वीकृत उत्तर को भी देखें।
इसे एक समुदाय विकी बनाएं, कृपया, "आम तौर पर स्वीकृत" पिन करना मुश्किल है। –