निम्नलिखित के रूप में वेब पृष्ठों के लिए RESTful यूआरएल डिजाइनिंग

Question

अधिकांश बाकी ट्यूटोरियल की व्यवस्था संसाधन:

GET /car/  -> list of cars 
GET /car/<id>/ -> info about specific car 
POST /car/  -> create a new car 

लेकिन जब ब्राउज़रों में उपयोग के लिए वेब अनुप्रयोगों के निर्माण के लिए, वहाँ एक लापता कड़ी है कि शायद ही कभी चर्चा कर रहे हैं, इससे पहले कि आप पोस्ट कर सकते हैं है/कार /, आपको एक नया संसाधन (कार) बनाने के लिए एक फॉर्म प्राप्त करने की आवश्यकता है। इस फॉर्म के लिए यूआरएल क्या होना चाहिए?

मैं आम तौर पर प्रयोग किया है:

GET /car/new/ -> form for creating a new car 
POST /car/new/ -> redirect to /car/<id>/ if item is created else show form with invalid fields highlighted 

लेकिन http://www.slideshare.net/Wombert/phpjp-urls-rest के अनुसार यह एक अच्छा बाकी URL नहीं है। मैं देख सकता हूं कि यह एक अच्छा आरईएसटी क्यों नहीं है, क्योंकि "नया" वास्तव में एक क्रिया के रूप में प्रयोग किया जाता है, न कि संसाधन, लेकिन फॉर्म कहां होना चाहिए, क्योंकि GET /car/ पहले से ही कारों को सूचीबद्ध करने के लिए उपयोग किया जाता है, इसलिए आप GET /car/ का उपयोग नहीं कर सकते नई कारों के लिए फार्म।

संक्षेप में, मेरा प्रश्न है: "संसाधन फ़ॉर्म बनाने के लिए रीस्टफुल यूआरएल क्या है?"

एक छोटे से संबंधित नोट पर, यहां तक ​​कि एक वेब सेवा में, कभी-कभी क्लाइंट पर भरोसा करना हमेशा बुद्धिमान नहीं होता है, इसलिए वेब सेवाओं में भी ग्राहक के लिए एक तरीका बनने की आवश्यकता हो सकती है संसाधन की वर्तमान स्कीमा का अनुरोध करें। AFAICS, यह एक समान रूप के रूप में एक निर्माण फ़ॉर्म प्राप्त करने की आवश्यकता के साथ है (यानी फॉर्म एक स्कीमा की तरह है जो बताता है कि संसाधन बनाने के लिए POST क्वेरी कैसे बनाएं)। क्या मेरी विचार की रेखा यहां सही है?

Answer 1

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

आपके थोड़ा संबंधित नोट के संबंध में, आप स्कीमा होने के रूप में क्या संकेत देते हैं मीडिया प्रकार है। रीस्टफुल आर्किटेक्चर क्लाइंट और सर्वर से संबंधित है जो दोनों मीडिया प्रकारों को समझते हैं जो आवेदन स्थिति का प्रतिनिधित्व करने के लिए उपयोग किए जाते हैं।

एक REST API में अपनी वर्णनात्मक प्रयास के लगभग सभी खर्च करना चाहिए, या विस्तारित संबंध नाम और/या हाइपरटेक्स्ट सक्षम निशान को परिभाषित करने में मीडिया प्रकार (ओं) संसाधनों का प्रतिनिधित्व करने और आवेदन राज्य ड्राइविंग के लिए इस्तेमाल को परिभाषित मौजूदा मानक मीडिया प्रकार के लिए। किसी भी ने ब्याज के यूआरआई पर उपयोग करने के तरीकों का वर्णन करने के लिए खर्च किए गए प्रयासों को मीडिया प्रकार के लिए प्रसंस्करण नियम के दायरे में पूरी तरह से परिभाषित किया जाना चाहिए (और, ज्यादातर मामलों में, पहले से ही मौजूदा मीडिया प्रकारों द्वारा परिभाषित किया गया है)।

यहां अधिक पढ़ें: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

रॉय फील्डिंग, आदमी है जो बाकी परिभाषित से है। आम तौर पर, आपके मीडिया प्रकारों को एक्स्टेंसिबल होना चाहिए - यानी, जब तक आवश्यक हो, पुराने क्लाइंट को किसी भी बदलाव को जोड़ना नहीं चाहिए।

Answer 2

मुझे हमेशा लगता है कि "फॉर्म" जैसे संसाधन नहीं है, इसलिए /<name>/new ठीक है - फॉर्म एपीआई के सामान्य तत्व नहीं हैं। स्लाइड के लेखक ने इसे "खराब" सूची में रखा, लेकिन एक सही प्रदान नहीं किया - मुझे लगता है कि वह इतना भरोसेमंद था कि वह ऐसे मामलों के बारे में सोचना भूल गया।