लिंक के साथ आरईएसटी संसाधन प्रतिनिधित्व, पीयूटी के साथ संगत और

Question

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

मैं पर ध्यान दिया है:

http://www.restapitutorial.com/media/RESTful_Best_Practices-v1_1.pdf

http://www.youtube.com/watch?v=HW9wWZHWhnI

अन्य ऑनलाइन संसाधनों के बीच

(मैं माफी उन सब को सूचीबद्ध नहीं कर सकता 2 लिंक करने के लिए सीमित कर रहा हूँ)। वे सभी महान हैं, लेकिन वास्तव में मेरे डिजाइन प्रश्न को संबोधित नहीं करते हैं।

सबसे अच्छा अभ्यास दस्तावेजों में से अधिकांश दो बातें बताते हैं कि मेरे लिए संघर्ष में थोड़ा देखो:

1) बाकी सेवा संसाधनों के बीच लिंक के रूप में डेटा रिश्तों का प्रतिनिधित्व करना चाहिए

2) एक एक से अनुरोध "डाल" क्लाइंट को पूर्ण प्रतिनिधित्व होना चाहिए, जो सर्वर पर दिखाई देने वाले प्रस्तुति के समान है।

मेरे दृष्टिकोण से परेशानी यह है कि लिंक, और शायद एक विशिष्ट संसाधन में कुछ अन्य गुण केवल पढ़ने के लिए हैं, इसलिए अपडेट नहीं किया जा सकता है। सर्वर स्पष्ट रूप से shoudl उन्हें उम्मीद करता है, और अगर यह सोचता है कि क्लाइंट उन्हें अद्यतन करने का प्रयास कर रहा है तो एक त्रुटि लौटाएं। वास्तव में, जब मैं JSON में प्रतिनिधित्व किए गए एक विशिष्ट संसाधन को देखता हूं, तो इसका अधिकांश डेटा वह डेटा होता है जो तर्कसंगत रूप से प्रतिस्थापित नहीं किया जा सकता/नहीं। जैसे

{ 
"link": { "rel":"self", "href":"http://example/project/12345" }, 
"team": { 
    "link": { "rel":"self", "href":"http://example/project/12345/team" }, 
    "title": "The project team" 
    }, 
    "title": "The Big Project" 
} 

यहाँ सबसे अच्छे रूप में केवल दो शीर्षक ग्रंथों इस संसाधन पर एक ग्राहक के लिए लिखने योग्य होना (टीम सदस्यता टीम लिंक के माध्यम से परिवर्तन के योग्य हो सकता है) होगा।

तो मुझे यह आवश्यक होना चाहिए कि एक पुट में सभी "लिंक" तत्वों को बिल्कुल समान रूप से शामिल किया जाए, जो पूरी तरह तार्किक और केवल पढ़ने योग्य हैं (उदाहरण में नोट करें, टीम को फिर से लिंक नहीं किया जा सकता है, क्योंकि संसाधन परिभाषित करता है यह परियोजना के लिए टीम के रूप में - इस मामले में इसे बदला जा सकता है, लेकिन कई संसाधन प्रकारों के लिए कठोर कंटेनरशिप के साथ, यह लागू नहीं होता है)?

क्या कई लिंक के साथ आरईएसटी में संसाधनों का प्रतिनिधित्व करने के लिए मानक पैटर्न या विरोधी पैटर्न हैं? मुझे एक विशिष्ट आरईएसटी संस्करण, जैसे हैटियोस के लिए नहीं कहा जा रहा है, हालांकि मेरा झुकाव सैद्धांतिक "शुद्धता" पर संभव है जहां संभव हो। दूसरे शब्दों में, यदि "आधिकारिक" आरईएसटी ग्राहकों को पूरे संसाधन, लिंक और सभी को पुट करने की अपेक्षा करेगा, तो शायद यही होगा कि मैं क्या करूँगा।

असली दुनिया जटिल गैर-पत्ती आरईएसटी संसाधनों के कुछ उदाहरण जो जीईटी और पीयूटी का समर्थन करते हैं, और इस प्रकार इस मुद्दे के साथ काम करना है, वास्तव में सराहना की जाएगी। जब मैं खोज करता हूं तो मुझे बहुत सारी राय मिलती है, और कई उदाहरण दिखाते हैं कि कैसे अच्छी तरह से काम करता है। । । लेकिन अब तक मैंने एक अच्छी तरह से प्रलेखित उदाहरण नहीं देखा है, लेकिन एक छोटे से पत्ते संसाधन (यानी एक जिसमें कोई लिंक नहीं है, शायद एक आत्म संदर्भ को छोड़कर) को PUT दिखा रहा है।

Answer 1

आपको "पूर्ण" प्रतिनिधित्व करना चाहिए क्योंकि आपका मीडिया प्रकार इसे परिभाषित करता है। यदि आप अपना खुद का मीडिया प्रकार डिज़ाइन कर रहे हैं, तो आपके विनिर्देश को परिभाषित करना चाहिए कि कौन से हिस्सों को म्यूटेबल होने का इरादा है और जिसका उद्देश्य अपरिवर्तनीय होना है।शोजी सूची प्रोटोकॉल, उदाहरण के लिए, को परिभाषित करता है a "body" member कि परिवर्तनशील डेटा शामिल करने का इरादा है:

सामान्य तौर पर, जब एक शरीर सदस्य मौजूद है, प्रोसेसर चाहिए संभावित परिवर्तनशील होने के लिए मूल्यों शरीर के भीतर मौजूद उम्मीद ( HTTP पुट या POST के माध्यम से, उदाहरण के लिए) और के बाहर किसी भी मूल्य की उम्मीद करनी चाहिए जो शरीर के सदस्य अपरिवर्तनीय हो; वह है, (संभावित रूप से) पर लिखने योग्य लेकिन अद्यतन पर नहीं। सर्वर नि: शुल्क हैं, निश्चित रूप से अनुमति देने के लिए या संसाधन के किसी भी हिस्से की व्यवहार्यता को अस्वीकार करते हैं। लेकिन "बॉडी" सदस्य की उपस्थिति डेटा के उस सदस्य के भीतर और उसके बिना दोनों की व्यवहार्यता के संबंध में मजबूत संकेत देती है।

यह एक मानक नहीं है (हालांकि यह मेरे लिए इतना स्पष्ट रूप से उपयोगी है कि मैं इसे एक (wink) बनना चाहता हूं)। ध्यान दें कि सर्वर जो कुछ भी ग्राहक द्वारा प्रस्तुत किए गए प्रतिनिधित्व के साथ करना चाहते हैं, वह करने के लिए स्वतंत्र हैं; किसी भी HTTP सर्वर के लिए सबसे मजबूत आवश्यकता यह है कि यह ग्राहक के इरादे को करने का प्रयास करता है (यदि सक्षम और अनुमति है)। यह कैसे और किस हद तक यह आपके विशेष अनुप्रयोग के लिए वास्तव में चिंता का विषय है, यही कारण है कि आप इसके बारे में किसी भी चश्मा में ज्यादा नहीं ढूंढ रहे हैं।

प्रैक्टिस में, मुझे सर्वर के लिए लिंक या किसी प्रस्तुति के अन्य अपरिवर्तनीय हिस्सों को सत्यापित करने के लिए उपयोगी नहीं मिला है; उन्हें बस अनदेखा कर दिया जाता है। इससे ग्राहकों को यह तय हो सकता है कि वे इस तरह से छोड़ सकते हैं। फिर, प्रैक्टिस में मुझे कोई समस्या नहीं मिली है।

Answer 2

मूल रूप से, एक GET अनुरोध है कि संसाधन के बारे में एक संसाधन के एक परिभाषित प्रारूप में श्रृंखलाबद्ध, और मेटाडाटा (जो एक साथ संसाधन का प्रतिनिधित्व गठन) वापस आ जाएगी। जब आप एक प्रतिनिधित्व वापस रख, यह मेटाडेटा की जरूरत नहीं है, न ही यह मूल (या बाद में किसी भी) अनुरोध प्राप्त के स्वरूप में ही होने की जरूरत है। सर्वर आपके द्वारा प्रदान किए गए प्रतिनिधित्व के आधार पर संसाधन अपडेट करेगा।

एचटीएमएल का एक उदाहरण <head> और <body> तत्व है, जो संसाधन के बारे में मेटाडेटा प्रदान करता है, और संसाधन प्रतिनिधित्व; और text/html और application/x-www-form-urlencoded सामग्री प्रकार, जो दो अलग-अलग प्रारूपों में संसाधन प्रस्तुतियों को स्थानांतरित करते हैं, पूर्व में मेटाडेटा के साथ, बाद वाले बिना। जब आप इसे करने के लिए पोस्ट करने के बाद संसाधन मिलता है, आप application/x-www-form-urlencoded -formatted डेटा प्राप्त करने की अपेक्षा नहीं है!

मुझे यकीन है कि आप "बाकी संस्करण" द्वारा क्या मतलब है नहीं कर रहा हूँ। केवल एक ही आरईएसटी है। यदि आप अन्य HTTP- आधारित एपीआई का जिक्र कर रहे हैं, तो कृपया उन्हें आरईएसटी न कहें। एपीआई शैलियों के बारे में अधिक जानकारी के लिए, Classification of HTTP-based APIs देखें।

अंत में, आप गैर-पत्ती PUT अनुरोध के उदाहरण के लिए पूछना।

1. संग्रह
2. उप-संसाधनों

संग्रह चलें कहते हैं कि तुम एक कार है: मुझे यकीन है कि आप, गैर पत्ती से वास्तव में क्या मतलब है के रूप में मैं दो प्रकार के बारे में सोच सकते नहीं कर रहा हूँ कैटलॉग, /cars पर उपलब्ध है। अगर आपने फैसला किया कि आप अपनी सभी कारों को मिटाना चाहते हैं, तो आप या तो DELETE /cars/1, DELETE /cars/2 ... आदि कर सकते हैं या आप PUT /cars को खाली निकाय या कोई सामग्री वाले सरणी के साथ चुन सकते हैं। उत्तरार्द्ध स्पष्ट रूप से बहुत अधिक कुशल होगा।

उप-संसाधनों इस विषय को जारी रखते हुए कहते हैं कि सुविधा देता है वहाँ एक कार, /cars/1 जो इस प्रकार प्रस्तुत किया जाता है यह है कि:

{ 
    "model":"Model-T", 
    "mfgr":"Ford", 
    "colour":"black" 
} 

अब, आप इन क्षेत्रों URL में द्वारा पहुँचा जा करने के लिए अनुमति देने के लिए इच्छा हो सकती है /cars/1/mfgr जो Ford या शायद {"mfgr":"Ford"} पर वापस आ जाएगा। अब यूआरएल /cars/1 गैर-पत्ती संसाधन का प्रतिनिधित्व करता है। हालांकि यूआरएल में एक नया प्रतिनिधित्व करने में अभी भी कोई समस्या नहीं है। इसलिए यह उप-संसाधन URL के मान भी अपडेट करेगा।

आखिरकार, आप JSON के माध्यम से हाइपरटेक्स्ट ट्रांसमिट करने के लिए HAL प्रारूप पर एक नज़र डालना चाहेंगे।