आराम से वेब सेवाएं

Question

यह सुनिश्चित करने के लिए कि आप इसे आरपीसी में नहीं बदल चुके हैं, एक विश्वसनीय इंटरफेस स्थापित करने से बचने के लिए आपको क्या चाहिए?

Answer 1

है:

• अपने आवेदन डिजाइन hypertext-driven (हाइपरमीडिया आवेदन राज्य के इंजन के रूप में - HATEOAS) किया जाना है।
• संसाधनों की पहचान करने और उनके प्रतिनिधित्व के लिए मीडिया प्रकारों को क्राफ्ट करने के अपने अधिकांश समय और प्रयास खर्च करें।
• पूरे यूआरआई को अपने संसाधन पहचानकर्ता के रूप में सोचें, और मान लें कि यह भविष्य में बदल जाएगा।
• अपने प्रतिनिधित्व के लिंक के रूप में अपने आवेदन के माध्यम से जारी रखने के लिए सभी विकल्प प्रदान करें।
• अपने एप्लिकेशन को वेबसाइट के रूप में सोचें जो ग्राहकों द्वारा 'क्रॉल' या 'ब्राउज' किया जाएगा।
• अपने एपीआई के लिए क्लाइंट लिखने का प्रयास करें और युग्मन कहां होता है इसकी तलाश करें।

मत करो:

• API दस्तावेज़ों में यूआरआई टेम्पलेट्स प्रकाशित करें। यदि आपके पास क्वेरी पैरामीटर के लिए टेम्पलेट्स होना चाहिए उदाहरण के लिए, सुनिश्चित करें कि वे आपकी मीडिया प्रकार परिभाषा का हिस्सा हैं।
• यूआरआई के संग्रह के रूप में आपके क्रिया के बारे में सोचें चार क्रियाओं पर कार्य किया जा रहा है।
• ग्राहकों के लिए "एप्लिकेशन/एक्सएमएल" या "एप्लिकेशन/जेसन" जैसे माइम प्रकारों की सेवा करें।

एक समानता का उपयोग करने के लिए, आपके एपीआई को अपने ग्राहकों के लिए एक जीपीएस की तरह काम करना चाहिए और मानचित्र की तरह कम करना चाहिए। आप केवल ग्राहकों को पास की सड़क के नाम के साथ प्रदान करेंगे।लेकिन तब से, वे केवल वही कर सकते हैं जो आपका आवेदन कहता है कि वे किसी भी बिंदु पर कर सकते हैं।

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

अधिकांश "रीस्टफुल" एपीआई इस पैटर्न का पालन नहीं करते हैं। ऐसा करने के लिए, Sun Cloud API और इसके backstory देखें।

Answer 2

एक व्यापक प्रश्न की तरह लेकिन मैं इसे आज़मा दूंगा। एक के लिए, केवल HTTP क्रियाओं का उपयोग करें कि कैसे इरादा किया गया था। एक यूआरएल तर्क के साथ एक यूआरएल पर पोस्ट न करें जो मूल रूप से POST को ओवरराइड करता है और उसे एक GET या DELETE में बदल देता है। इस प्रकार एसओएपी काम करता है (सबकुछ एक पोस्ट है)।

Answer 3

जहां संभव हो अंतर्निहित प्रोटोकॉल का लाभ उठाएं। अपने पेलोड में क्रियाएं करने के बजाए (उदाहरण के लिए) HTTP प्राप्त करें, पोस्ट करें, पुट करें, विधियों को हटाएं। आपके यूआरआई को संसाधन का वर्णन करना चाहिए, लेकिन इसके साथ क्या नहीं करना चाहिए।

Answer 4

बातें आप से बचना चाहते हैं से कुछ हैं:

• की उपेक्षा कर कैशिंग
• टनेलिंग सब कुछ प्राप्त के माध्यम से (या वैकल्पिक रूप पोस्ट)
• MIME प्रकार की उपेक्षा कर

एक अच्छा लेख है यहां कुछ आरईएसटी विरोधी पैटर्न के बारे में बात करते हैं:

http://www.infoq.com/articles/rest-anti-patterns

Answer 5

इस लेख में वर्णन कुछ डिजाइन फैसले कि बाकी हिस्सों से आरपीसी अंतर:

http://www.pluralsight.com/community/blogs/tewald/archive/2007/04/28/47067.aspx

@ S.Lott: धन्यवाद, मैं ईमानदारी से सोचा था कि मैं तैनात था कि जवाब के रूप में नहीं एक टिप्पणी। मैं अपने पत्थर खो रहा हूँ।