क्या REST और HATEOAS वेब सेवाओं के लिए एक अच्छी वास्तुकला है?

Question

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

REST आर्किटेक्चर को API के लिए REST आर्किटेक्चर लागू करके बनाया गया था। लेकिन क्या वास्तव में यह सोचने का कोई कारण है कि REST इस डोमेन के लिए एक वांछनीय वास्तुकला है? अधिक विशेष रूप से, क्या कोई सबूत है जो कहते हैं कि HATEOAS मशीन-टू-मशीन संचार के लिए एक लाभदायक डिजाइन सिद्धांत है?

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

Comments

चूंकि वेब HTTP उपयोग पर आधारित है, और REST HTTP है, इसलिए मुझे लगता है कि यह उपयोग करने के लिए एक उत्कृष्ट चीज है।

— रोब

@Rob: HTTP से ज्यादा REST। उदाहरण के लिए SOAP और XML-RPC भी HTTP का उपयोग करती है लेकिन REST के अनुरूप नहीं है।

— जाकबीस

न तो REST आर्किटेक्चर पर आधारित है। इसलिए अंतर।

— रोब

यह वास्तव में कठिन सवाल है। क्योंकि आखिरकार यह किसी भी पिछली या वर्तमान तकनीक जितना अच्छा या बुरा है। यह आपके टास्क पर निर्भर करता है। कुछ टास्क के लिए यह काम करता है। दूसरों के लिए हम ग्राफकल या फाल्कोर / जेएसग्राफ में जा रहे हैं। या फिर बाइनरी (जीआरपीसी) फिर से प्रचलित है। मेरे दृष्टिकोण से HATEOAS और "स्मार्ट क्लाइंट" का वादा पूरा नहीं हुआ। ओवरहेड ने इसे मार दिया।

— थॉमस जंक

यह कई चीजों पर निर्भर करता है। उनमें से सभी तकनीकी मुद्दे नहीं हैं। निहितार्थ और निष्पादन से संबंधित संदर्भ मायने रखता है।

— Laiv

Answer 1

AFAIK क्षेत्ररक्षण ने दावा नहीं किया कि REST कोई भी अच्छा था, वह सिर्फ वेब की वास्तविक संरचना का वर्णन कर रहा था।

वह इसे थोड़ा रेखांकित करता है, मुझे लगता है। REST, आखिरकार, आर्किटेक्चरल शैली की एक गणना है जो फ़ील्डिंग HTTP / 1.1 कल्पना के मुख्य वास्तुकार के रूप में उपयोग कर रही है ।

लेकिन क्या वास्तव में यह सोचने का कोई कारण है कि REST इस डोमेन के लिए एक वांछनीय वास्तुकला है? क्या कोई सबूत है जो कहते हैं कि HATEOAS मशीन-टू-मशीन संचार के लिए एक लाभदायक डिजाइन सिद्धांत है?

"निर्भर करता है"। HATEOAS REST की एकसमान इंटरफ़ेस बाधा का हिस्सा है ।

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

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

यह सिर्फ काम करता है ।

यह निश्चित रूप से सार्वभौमिक नहीं है। 2008 में फील्डिंग, ने लिखा:

इसका मतलब यह नहीं है कि मुझे लगता है कि हर किसी को अपने सिस्टम को REST आर्किटेक्चरल स्टाइल के अनुसार डिजाइन करना चाहिए। आरईएसटी लंबे समय तक रहने वाले नेटवर्क-आधारित अनुप्रयोगों के लिए अभिप्रेत है जो कई संगठनों को फैलाते हैं। यदि आपको बाधाओं की आवश्यकता नहीं है, तो उनका उपयोग न करें।

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

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

schema.org एक मशीन पठनीय शब्दावली बनाने के प्रयास का एक हिस्सा है; मशीन एजेंट क्लाइंट को सिमेंटिक संकेत खोजने के लिए उपयोग करते हैं, और सही कार्यों को लेने के लिए अर्थ की अपनी समझ को लागू करते हैं।

लेकिन यह काम है; आपको अपने संसाधनों के मशीन के अनुकूल अभ्यावेदन को विकसित करने में निवेश करने की आवश्यकता है, और यह सुनिश्चित करना कि वे अभ्यावेदन आगे और पीछे संगत रहें, ताकि ग्राहकों को स्वतंत्र रूप से विकसित किया जा सके।

जब एक एकल संगठन क्लाइंट और सर्वर दोनों को नियंत्रित करता है, तो इस स्वतंत्रता के लाभ बहुत छोटे होते हैं, इस मामले में बाधा एक उपयुक्त वास्तुशिल्प विकल्प नहीं हो सकती है।

Comments

दिलचस्प जवाब। ऐसा लगता है, विशेष रूप से इस उद्धरण के आधार पर " REST इंटरफ़ेस बड़े-अनाज हाइपरमीडिया डेटा स्थानांतरण के लिए कुशल होने के लिए डिज़ाइन किया गया है, जो वेब के सामान्य मामले के लिए अनुकूलन करता है, लेकिन परिणामस्वरूप एक इंटरफ़ेस जो वास्तुशिल्प बातचीत के अन्य रूपों के लिए इष्टतम नहीं है। "फील्डिंग सेवा API के लिए REST आर्किटेक्चर इष्टतम पर विचार नहीं करेगा । (बेशक बाकी अभी भी SOAP से बेहतर है, भले ही यह इष्टतम न हो!)

— जैक्सबीस

यह कहना मुश्किल है कि फील्डिंग क्या इष्टतम पर विचार करेगी :-)। मुझे लगता है कि कुछ एपीआई की ज़रूरतों में बड़े आकार के हाइपरमीडिया डेटा ट्रांसफर शामिल हैं।

— Laiv

Answer 2

नहीं, 'पूरा REST' उतना महान नहीं है।

जैसा कि उन लोगों की कमी के सबूत के रूप में किया गया है जो HierOS को अपने API में कार्यान्वित करते हैं और उन अंतहीन तर्कों पर जो किसी विशेष कॉल के लिए HTTP क्रिया का उपयोग करते हैं।

लेकिन आपको यह पहचानना होगा कि REST इतना लोकप्रिय क्यों है। इसके गोद लेने से पहले विभिन्न पागल जटिल प्रोटोकॉल थे जैसे कि ईबेक्सएमएल और एसओएपी जिसमें पावती, टाइमआउट, वार्तालाप आईडीएस और राज्य शामिल थे।

इन बातों को ठीक और चालू और उसके बाद समझा उन्हें एपीआई के उपभोक्ताओं के लिए कठिन कार्य था। "मैं क्वेरी आईडी में जो आईडी चाहता हूं उसके साथ मैं सिर्फ एक GET क्यों नहीं करता और आप मुझे डेटा भेजते हैं?" एक स्पष्ट और सामान्य प्रश्न था।

तब दूसरी समस्या एक्सएमएल थी, जावास्क्रिप्ट ने इसे समझ नहीं पाया, स्कीमा को गांड में दर्द था और आप बड़ी-बड़ी txt फ़ाइलों के साथ अंत में शामिल होंगे <MyLongObjectName>। इसलिए लोगों ने JSON का उपयोग करना शुरू कर दिया।

अब REST के पास इसके चारों ओर एक पंथ है, लेकिन क्योंकि नियम इतने अस्पष्ट हैं कि यह आपको उपयोग करने योग्य API को दस्तक देने से नहीं रोकता है जो कि इतना सरल है कि उपभोक्ता इसे 'प्राप्त कर लेंगे' और इसे बोर्डिंग पर 6 महीने के बिना उपयोग कर सकते हैं। प्रक्रिया।

Comments

फील्डिंग की अक्सर बताई गई शिकायतों में से एक है, REST को समझने और उचित कार्यान्वयन के लिए लोगों की कमी। यह REST की विफलता नहीं है। और ना ही Javascript की XML के साथ REST के साथ कोई समस्या है। और जावास्क्रिप्ट और XML दोनों का REST से कोई लेना देना नहीं है। फील्डिंग ने खुद को ऑनलाइन उपलब्ध कराया था, अपने शोध प्रबंध के बाहर लेख लिखे, उचित रीस्ट उपयोग के उदाहरणों की ओर इशारा किया, और लोगों को लगता है कि उनके लेखन और HTTP के कार्यान्वयन को समझने में कोई समस्या नहीं है, ऐसा लगता है कि कई मुद्दों को समझना नहीं चाहिए और ठीक से REST लागू करना।

— रोब

XML का इस पर कोई असर नहीं है कि REST एक अच्छा API आर्किटेक्चर है या नहीं, मानक में ऐसा कुछ भी नहीं है जो XML को संसाधन प्रारूप के रूप में आवश्यक हो। JSON, HTML, सादा पाठ अन्य सभी के बीच सभी वैध संसाधन हैं।

— पॉल

मुझे लगता है कि जब REST के बारे में बात की जाती है तो हमें दोनों को पहचानना होगा कि मानक क्या है और लोग वास्तविकता में क्या लागू करते हैं और फिर CALL 'REST'

— Ewan

Answer 3

यह ध्यान रखना है कि रॉय आरईएसटी के अधिकांश सिद्धांतों का मूल आविष्कारक नहीं था, वह कई सिद्धांतों को एक साथ रखता है जिन्हें विभिन्न विशिष्ट समस्याओं को हल करने के लिए पिछले सिस्टम में काम करने के लिए जाना जाता है। REST एक ही वास्तुकला में इन सिद्धांतों को लागू करने का स्वाभाविक निष्कर्ष है।

रॉय फील्डिंग ने REST पर अपना शोध प्रबंध लिखने से पहले ही, HTTP को पहले से ही उन सिद्धांतों के आसपास तैयार किया गया था, जिन्हें बाद में REST के रूप में जाना जाता है। अपने शोध प्रबंध के निष्कर्ष में , उन्होंने लिखा:

मौजूदा हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP / 1.0) [19] को परिभाषित करने के लिए इंटरनेट इंजीनियरिंग टास्कफोर्स के भीतर हमारे प्रयासों की शुरुआत में और HTTP / 1.1 [42] और यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) [21] के नए मानकों के लिए एक्सटेंशन डिज़ाइन करें ], मैंने एक मॉडल की आवश्यकता को पहचाना कि वर्ल्ड वाइड वेब को कैसे काम करना चाहिए। एक समग्र वेब अनुप्रयोग के भीतर बातचीत का यह आदर्श मॉडल, जिसे प्रतिनिधि राज्य हस्तांतरण (REST) ​​स्थापत्य शैली के रूप में संदर्भित किया जाता है, आधुनिक वेब वास्तुकला की नींव बन गया, मार्गदर्शक सिद्धांत प्रदान करता है जिसके द्वारा preexisting वास्तुकला में खामियों की पहचान की जा सकती है और विस्तार किया जा सकता है। तैनाती से पहले मान्य ।

REST और HATEOS उस समस्या के लिए एक उपयुक्त है जो इसके लिए डिज़ाइन की गई थी:

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

हालांकि, यह ध्यान दिया जाना चाहिए कि वेब और रीस्ट जरूरी नहीं कि हर समस्या के लिए एक अच्छा फिट हो:

इसी तरह, प्रस्तावित एक्सटेंशन को REST से तुलना करके देखा जा सकता है कि क्या वे वास्तुकला के भीतर फिट होते हैं; यदि नहीं, तो यह एक अधिक लागू वास्तुशिल्प शैली के साथ समानांतर में चल रहे सिस्टम के लिए उस कार्यक्षमता को पुनर्निर्देशित करने के लिए अधिक कुशल है।

तो अगर आपका सवाल है "क्या REST और HATEOAS वेब सेवाओं के लिए एक अच्छा आर्किटेक्चर है?" फिर, जवाब बस "हाँ, यह वेब सेवाओं के लिए एक अच्छा आर्किटेक्चर है"। समस्या वास्तव में यह है कि क्या सभी समस्याओं को लोगों ने उन्हें वेब बाधाओं में रेट्रोफिटिंग द्वारा हल करने की कोशिश की, वास्तव में पहली जगह में वेब सेवाएं होनी चाहिए थीं।

कई API हैं जो वास्तव में REST फिट नहीं करते हैं। एपीआई जिन्हें स्केलेबिलिटी की जरूरत नहीं है, जिन्हें REST हल करने के लिए डिज़ाइन किया गया है, वे कई संगठनों द्वारा उपभोग नहीं किए जाते हैं जो स्वतंत्र रूप से विकसित हो सकते हैं, और उन्हें लंबे समय तक रहने की आवश्यकता नहीं है; इन समस्याओं के लिए, REST बाधाएं केवल एक स्ट्रेटजैकेट हैं।

लेकिन क्या वास्तव में यह सोचने का कोई कारण है कि REST इस डोमेन के लिए एक वांछनीय वास्तुकला है? अधिक विशेष रूप से, क्या कोई सबूत है जो कहते हैं कि HATEOAS मशीन-टू-मशीन संचार के लिए एक लाभदायक डिजाइन सिद्धांत है?

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

Answer 4

एडोब अनुभव प्रबंधक पर क्षेत्ररक्षण की प्रस्तुति में:

बाकी एक वास्तुकला नहीं है!

बाकी एक वास्तुशिल्प शैली है, जो इंटरनेट पर मौजूद विभिन्न वास्तुकला का अमूर्त रूप है।

आरईएस वास्तुशिल्प गुणों को प्रेरित करने के लिए डिजाइन की कमी का एक संचय है

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

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

AEM में REST

Answer 5

यदि आप जो चाहते हैं वह एक ऐसी सेवा बनाना है जो किसी अन्य सर्वर द्वारा खपत की जाती है, तो xmlrpc सही विकल्प है। यदि आप चाहते हैं कि पतली ग्राहकों या कम बिजली उपकरणों द्वारा उपभोग की जाने वाली एक सेवा है .. या खुले इंटरनेट पर अज्ञात ग्राहक शायद आगजनी का उपयोग करके आराम करें। लेकिन याद रखें, जब xml की तुलना में सामान्य डेटा को निर्दिष्ट करने के लिए json एक अवर संकेतन है।

Comments

क्यों JSON xml से नीच है?

— मल्की

@ Malky.Kid: निश्चित रूप से कोई भी हमेशा JSON के रूप में किसी XML दस्तावेज़ का प्रतिनिधित्व करने का एक तरीका खोज सकता है, इसलिए JSON आपके साथ इसे व्यक्त करने में हीन नहीं है। लेकिन XML, एक चीज़ के लिए, बॉक्स से बाहर मेटाडेटा को व्यक्त करने के लिए और वाक्यविन्यास क्षमता प्रदान करता है (स्कीमा, प्रकार की जानकारी, टिप्पणियां, नाम स्थान, प्रसंस्करण निर्देश, यहां तक ​​कि उपयोग किए जाने वाले वर्ण एन्कोडिंग) हर किसी को डेटा स्कीमा का आविष्कार और निर्णय लेने के बिना। उनके लिए इन चीजों को करना (जैसा कि यह JSON के साथ है), इसलिए उस अर्थ में मुझे लगता है कि यह कहना उचित है कि यह JSON की बेहतर क्षमता प्रदान करता है।

— स्टैक