REST API हाइपरटेक्स्ट पर आधारित होना चाहिए

"और आप उस पर विश्वास करते थे?" खुर लोकपाल ने फटकारते हुए कहा। "अच्छा, आपको क्या लगता है, क्या मैं आपकी अनुमति के बिना इन वज़न को ले चुका होता?"

"तो आप वजन लिया?" रोया ओस्ताप। - क्यों?

- पैनिकोव्स्की ने कहा कि वे सोने के हैं।

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

क्लासिक्स के इस टुकड़े के साथ, मैं रॉय टी। फील्डिंग ब्लॉग पोस्ट REST API के अनुवाद को प्राथमिकता देना चाहूंगा जो हाइपरटेक्स्ट-चालित होना चाहिए। सामग्री के लिंक के लिए habr.com/users/arthuriantech का विशेष धन्यवाद।

हैबे पर इस सप्ताह को आरईएसटी (पूर्ण) एपीआई के सप्ताह के रूप में चिह्नित किया गया था। इस अर्थ में, मैं हमेशा इस शब्द में REST उपसर्ग की उपस्थिति से भ्रमित था। और, जैसा कि यह निकला, सिर्फ मैं ही नहीं। आज मैं खुद इसे पढ़ूंगा और सभी को यह जानने के लिए आमंत्रित करूंगा कि रॉय टी। फील्डिंग ने 2008 में इसके बारे में क्या सोचा था। बेशक, कोई व्यक्ति एक स्टूल पर घबराता है और कहता है: रॉय को बताएं, बेन्या रेस्ट एपीआई के लिए जानता है। फिर भी, हम शुरू करेंगे।

मैं यह सोचकर निराश हूं कि कितने लोग HTTP प्रोटोकॉल REST API के आधार पर किसी भी इंटरफ़ेस को कॉल करते हैं। आज का उदाहरण REST सोशलसाइट एपीआई है। यह एक RPC है। यह एक स्पष्ट RPC है। यह इस तरह के कठिन लिंक को प्रदर्शित करता है कि यह कठिन पोर्न की श्रेणी को सौंपने का समय है।

क्या करने की आवश्यकता है ताकि वे समझें कि हाइपरटेक्स्ट आरईएसटी वास्तुकला में एक आवश्यक तत्व है? दूसरे शब्दों में, यदि एप्लिकेशन स्टेट मैकेनिज्म (और इसलिए एपीआई) हाइपरटेक्स्ट आधारित नहीं है, तो यह Restful नहीं हो सकता है और REST API नहीं हो सकता है। बिंदु। इसे स्पष्ट करने के लिए मुझे किस पुस्तक को फिर से लिखना चाहिए?

API डेवलपर, अपने REST API कृतियों को कॉल करने से पहले निम्नलिखित नियमों पर ध्यान दें:

REST API किसी विशिष्ट संचार प्रोटोकॉल पर निर्भर नहीं होना चाहिए, हालाँकि इस प्रोटोकॉल के लिए इसकी सफल मैपिंग मेटाडेटा की उपलब्धता, विधियों की पसंद आदि पर निर्भर हो सकती है। सामान्य तौर पर, URI स्कीम में कोई भी प्रोटोकॉल पहचान के लिए किसी भी URI स्कीम का उपयोग करने की अनुमति देता है। [यहाँ त्रुटि यह है कि पहचान बातचीत से अलग नहीं है।]

REST API में मानक प्रोटोकॉल के अपर्याप्त रूप से परिभाषित बिट्स, जैसे HTTP PATCH विधि या लिंक हेडर फ़ील्ड के विवरण को भरने या सुधारने के अलावा, संचार प्रोटोकॉल में कोई परिवर्तन नहीं होना चाहिए। गैर-कार्यशील कार्यान्वयन के लिए वर्कअराउंड (जैसे ब्राउज़र जो विश्वास करने के लिए पर्याप्त हैं कि एचटीएमएल HTTP तरीकों का एक सेट परिभाषित करता है) को अलग से या कम से कम अनुप्रयोगों में निर्धारित किया जाना चाहिए, इस उम्मीद के साथ कि वर्कअराउंड अंततः अप्रचलित हो जाएगा। [यहाँ त्रुटि यह है कि संसाधन इंटरफेस विशिष्ट हैं और सार्वभौमिक नहीं हैं।]

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

REST API को निश्चित संसाधन नाम या नामस्थान (तंग क्लाइंट-सर्वर कनेक्टिविटी) को परिभाषित नहीं करना चाहिए। नौकरों को अपने नामस्थानों को प्रबंधित करने की स्वतंत्रता होनी चाहिए। इसके बजाय, सर्वरों को क्लाइंट को निर्देश देते हैं कि उपयुक्त URI कैसे बनाएं, उदाहरण के लिए, HTML रूपों और URI टेम्प्लेट में, इन निर्देशों को मीडिया प्रकारों और संदर्भ संबंधों में परिभाषित करते हुए। [यहाँ त्रुटि यह है कि संसाधन की संरचना इस संसाधन के बाहर सेट है, उदाहरण के लिए, एक डोमेन-विशिष्ट मानक में, जो वास्तव में RPC के कार्यात्मक संबंध का एक एनालॉग है]।

REST API में क्लाइंट के लिए महत्वपूर्ण "टाइप" संसाधन नहीं होने चाहिए। विनिर्देश लेखक इंटरफ़ेस के पीछे सर्वर कार्यान्वयन का वर्णन करने के लिए संसाधन प्रकारों का उपयोग कर सकते हैं, लेकिन ये प्रकार क्लाइंट के लिए अप्रासंगिक और अदृश्य होने चाहिए। क्लाइंट के लिए महत्वपूर्ण एकमात्र प्रकार वर्तमान दृश्य और मानकीकृत संबंध नामों के मीडिया प्रकार हैं। [वी इसके बाद के संस्करण]

REST API को प्रारंभिक URI के अलावा किसी भी पूर्व ज्ञान के बिना दर्ज किया जाना चाहिए और लक्षित दर्शकों के लिए उपयुक्त मानकीकृत मीडिया प्रकारों का एक सेट (अर्थात क्लाइंट पक्ष पर अपेक्षित है, जो API का उपयोग कर सकता है)। इस क्षण से, एप्लिकेशन स्टेट्स के सभी संक्रमणों को सर्वर द्वारा प्रदान किए गए विकल्पों के विकल्प द्वारा निर्धारित किया जाना चाहिए जो प्राप्त विचारों में मौजूद हैं, या इन विचारों के साथ उपयोगकर्ता के जोड़-तोड़ द्वारा। मीडिया के प्रकार और संसाधन संचार तंत्र के ग्राहक के ज्ञान से संक्रमण का निर्धारण (या सीमित) किया जा सकता है जिसे मक्खी (उदाहरण के लिए, अनुरोध पर कोड) में सुधार किया जा सकता है। [यहाँ त्रुटि यह है कि संसाधन के लिए बाहरी जानकारी हाइपरटेक्स्ट के बजाय इंटरैक्शन को नियंत्रित करती है।]

शायद मैं कुछ याद कर रहा हूं, लेकिन ऊपर दिए गए नियम हैं जो हाइपरटेक्स्ट के लिए आवश्यक हैं, जो तथाकथित टेस्ट एपीआई में सबसे अधिक बार उल्लंघन किया जाता है। कृपया उनके साथ रहने की कोशिश करें या अपने एपीआई के लिए एक और चर्चा का चयन करें।

रॉय टी। फील्डिंग के इस पोस्ट ने टिप्पणियों में एक चर्चा छेड़ दी। मैं चर्चा के भाग से परिचित होने का प्रस्ताव करता हूं, जो लेखक के उत्तरों के साथ था।

प्रश्न:

किस अर्थ में आप यहाँ "हाइपरटेक्स्ट" शब्द का उपयोग करते हैं? क्या मुझे यह समझने के लिए आपके काम को पढ़ना होगा या क्या ऑनलाइन कुछ ऐसा है जो इस अवधारणा का अर्थ बताता है?

उत्तर है:

मेरी REST बात में एक स्लाइड है जो बताती है कि हाइपरटेक्स्ट (और हाइपरमीडिया) का क्या अर्थ है।

हाइपरटेक्स्ट की कई परिभाषाएँ हैं:

टेड नेल्सन की प्रारंभिक परिभाषा गैर-रेखीय दस्तावेजों पर केंद्रित थी।

"हाइपरटेक्स्ट" से मेरा मतलब है एक गैर-रेखीय दस्तावेज़ - एक पाठ जो कांटे और पाठक को एक विकल्प बनाने की अनुमति देता है, एक दस्तावेज जो एक इंटरैक्टिव स्क्रीन पर पढ़ना आसान है। यह आम तौर पर स्वीकार किया जाता है कि यह पाठ के लिंक का एक लिंक है जो पाठक को विभिन्न मार्गों की पेशकश करता है। [थियोडोर एच। नेल्सन]


हाइपरटेक्स्ट बाद में एक विशिष्ट उपयोगकर्ता इंटरफ़ेस तंत्र के साथ जुड़ गया।

हाइपरटेक्स्ट एक कंप्यूटर-समर्थित स्टोरेज माध्यम है जिसमें संबंधित दस्तावेज़ों को एक उच्च रिज़ॉल्यूशन वाली कंप्यूटर स्क्रीन पर उनके लिंक के साथ प्रदर्शित किया जाता है। [जेफरी कोंक्लिन]


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

हाइपरटेक्स्ट को ब्राउज़र के लिए HTML नहीं होना चाहिए। जब वे डेटा प्रारूप और संबंध प्रकारों को समझते हैं तो मशीनें लिंक का अनुसरण कर सकती हैं।

डेव जॉनसन (आलोचना एपीआई के लेखक):

शायद मैंने एक फजी शब्द दिया। मेरा कभी भी यह दावा करने का मतलब नहीं था कि OpenSocial या SocialSite RPC API RESTful थे। मेरे ब्लॉग पर अधिक करें rollerweblogger.org/roller/entry/the_x_rated_socialsite_api ।

उत्तर है:

OpenSocial RESTful प्रोटोकॉल RESTful नहीं है। यह अपेक्षाकृत छोटे परिवर्तनों के साथ तय किया जा सकता है, लेकिन अब यह RPC के परिणाम को सामान्य प्रकार के वेब मीडिया में पैक कर रहा है।

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

इंटरनेट के संदर्भ में इसके बारे में सोचें। ऑनलाइन बैंकिंग संसाधन और विकी के बीच अंतर के बारे में कितने वेब ब्राउज़र जानते हैं? उनमें से एक भी नहीं। उन्हें संसाधन प्रकारों के बारे में जानने की आवश्यकता नहीं है। उन्हें संभावित स्टेट ट्रांज़िशन: लिंक और फॉर्म: और इन लिंक को ट्रेस करने पर किस तरह के शब्दार्थ या क्रिया निहित है, यह जानने की आवश्यकता है। ब्राउज़र उन्हें अलग-अलग उपयोगकर्ता इंटरफ़ेस नियंत्रण के रूप में प्रस्तुत करता है ताकि उपयोगकर्ता संभावित बदलाव देख सके और चयनित कार्यों के प्रभाव का अनुमान लगा सके। बॉट उनका पालन इस हद तक कर सकते हैं कि यह ज्ञात हो कि कार्रवाई सुरक्षित है। टाइप किए गए रिश्ते, विशिष्ट मीडिया प्रकार और एक्शन से संबंधित तत्व स्वचालित एजेंटों के लिए आवश्यक मार्गदर्शन प्रदान करते हैं।

उपयोगी लिंक:
1. अनुवाद संस्करण habr.com/us/users/arthuriantech से

2. पुरानी रॉय की वही थीसिस