अब यह 2013 है - आप आंशिक अद्यतन के लिए PATCH का उपयोग करना चाहिए - या तो json-पैच का उपयोग कर या एक्सएमएल-पैच दस्तावेजों (http://tools.ietf.org/html/rfc7351 देखें) (http://tools.ietf.org/html/rfc6902 या http://www.mnot.net/blog/2012/09/05/patch देखें)। हालांकि मेरी राय में, जेसन-पैच आपके प्रकार के व्यावसायिक डेटा के लिए सबसे अच्छा फिट है।
जेएसओएन/एक्सएमएल पैच दस्तावेज़ों के साथ पैच आंशिक अपडेट के लिए बहुत ही आगे की सैमसंग है। यदि आप मूल दस्तावेज़ की संशोधित प्रतियों के साथ POST का उपयोग शुरू करते हैं, तो आंशिक अपडेट के लिए आप जल्द ही उन समस्याओं में भाग लेते हैं जहां आप "इस संपत्ति को अनदेखा करें" या "इस संपत्ति को सेट करें" का प्रतिनिधित्व करने के लिए अनुपलब्ध मान (या, बल्कि, शून्य मान) चाहते हैं। खाली मूल्य "- और यह हैक किए गए समाधानों के खरगोश छेद को नीचे ले जाता है जो अंत में आपके स्वयं के पैच प्रारूप का परिणाम देगा।
आप यहां अधिक गहन उत्तर पा सकते हैं: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html।
अपडेट: क्या यह आरपीसी है?
ठीक है, यदि आप आरपीसी को सर्वर पर कमांड भेजने के रूप में परिभाषित करते हैं तो किसी भी और सभी HTTP संचालन आरपीसी कॉल हैं - चाहे आप संसाधन प्राप्त करें, एक नया प्रतिनिधित्व दें या फिर इसे हटा दें - उनमें से प्रत्येक को एक भेजने आदेश (क्रिया) प्राप्त/पुट/हटाएं आदि और एक वैकल्पिक पेलोड। ऐसा होता है कि HTTP वर्किंग ग्रुप (या जो कभी भी है) ने एक नया क्रिया पैच पेश किया है जो ग्राहकों को संसाधन के आंशिक अपडेट करने की अनुमति देता है।
यदि सर्वर को पूर्ण प्रतिनिधित्व भेजने से कुछ और आरपीसी शैली माना जाता है, तो परिभाषा के अनुसार, आंशिक अपडेट रीस्टफुल नहीं हो सकते हैं। कोई भी इस दृष्टिकोण को चुनने का विकल्प चुन सकता है, लेकिन वेब इंफ्रास्ट्रक्चर के पीछे के लोग अलग-अलग कहते हैं - और इस प्रकार इस उद्देश्य के लिए एक नया क्रिया परिभाषित किया है।सोप का उपयोग कर विधि के नाम और पैरामीटर रैप करने के लिए उदाहरण के लिए -
आरपीसी सुरंग विधि के बारे में अधिक एक तरीका है कि वेब पर बिचौलियों के लिए अदृश्य है में HTTP के माध्यम से कहता है। ये ऑपरेशन "अदृश्य" हैं क्योंकि पेलोड के अंदर विधियों और पैरामीटर को परिभाषित करने के लिए कोई मानक नहीं है।
मीडिया प्रकार के आवेदन/जेसन-पैच के साथ पैच में इसकी तुलना करें - ऑपरेशन का इरादा वेब पर किसी भी मध्यस्थ के लिए स्पष्ट रूप से दिखाई देता है क्योंकि क्रिया पैच का एक अच्छी तरह से परिभाषित अर्थ है और पेलोड को अन्य अच्छी तरह से परिभाषित किया गया है वेब पर सामान्य प्राधिकरण के स्वामित्व वाले सार्वजनिक उपलब्ध प्रारूप (आईईटीएफ)। शुद्ध परिणाम सभी के लिए पूर्ण दृश्यता है और कोई एप्लिकेशन विशिष्ट गुप्त अर्थशास्त्र नहीं है।
आरईएसटी "serendipitous reuse" के बारे में भी है जो एप्लिकेशन/जेसन-पैच के साथ पैच है - एप्लिकेशन विशिष्ट प्रोटोकॉल का आविष्कार करने के बजाय मौजूदा मानक का पुन: उपयोग करना जो कम या ज्यादा करता है।
स्रोत
2013-01-02 23:25:01
मैं सिर्फ http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html पढ़ सकते हैं और यह मेरे लिए आरपीसी की तरह बदबू आ रही है। संसाधन संसाधनों के बजाय हम आदेश भेज रहे हैं (उदा। इसे जोड़ें, इसे प्रतिस्थापित करें)। यह एक एसओएपी दुनिया में अच्छी तरह फिट हो सकता है, लेकिन मेरी राय में आरईएसटी फिट नहीं है। – Gili
मैं इस कवर करने के लिए मेरा उत्तर अद्यतन किया है - यह काफी कुछ और पात्रों की आवश्यकता की तुलना में एक टिप्पणी में अनुमति दी है। –
सब ** व्यावहारिक ** प्रयोजनों के एक पैच के लिए लगभग एक पोस्ट करने के लिए समान है। प्रॉक्सी 'पाथ' का इलाज 'POST' (परिणामस्वरूप राज्य की कोई कैशिंग नहीं) के रूप में करेंगे। कोई प्रॉक्सी सभी 'पैच' प्रकारों को लागू करने से परेशान नहीं होगा। पैच को स्वचालित रूप से बनाने/अनपॅक करने के लिए एकमात्र व्यावहारिक लाभ क्लाइंट-साइड और सर्वर-साइड लाइब्रेरी हो सकता है। क्या यह वास्तव में पहली जगह में हल करने में एक समस्या थी? संदिग्ध। मुझे नहीं लगता कि मैं एक बेहतर समाधान के साथ आ सकता था। मैं सिर्फ 'पैच' को परिभाषित करने का कह रहा हूं, वास्तव में वहां से पहले जो कुछ भी पहले से बाहर था, उससे ज्यादा मूल्य नहीं जोड़ता है। – Gili