REST HATEOAS (परिपक्वता स्तर 3) कितना उपयोगी / महत्वपूर्ण है?

110

मैं एक ऐसी परियोजना में शामिल हो रहा हूँ जहाँ टीम के कुछ वरिष्ठ सदस्यों का मानना है कि एक REST API को HATEOAS के अनुरूप होना चाहिए और सभी रिचर्डसन की परिपक्वता के स्तर को लागू करना होगा ( http://martinfowler.com/articles/richardsonMaturityModity.html )!

AFAIK अधिकांश रीस्ट कार्यान्वयन HATEOAS के अनुरूप नहीं हैं और एक अच्छा कारण होना चाहिए कि अधिक लोग ऐसा क्यों नहीं कर रहे हैं। मैं जोड़ा जटिलता, फ्रेमवर्क (सर्वर और क्लाइंट पक्षों) की कमी, प्रदर्शन चिंता और जैसे कारणों के बारे में सोच सकता हूं ...

तुम क्या सोचते हो? क्या आपको वास्तविक विश्व परियोजना में HATEOAS के साथ कोई अनुभव है?

rest hateoas

— mhdwrk
स्रोत

यहाँ इस विषय पर एक अच्छा लेख है: medium.com/@andreasreiser94/... यह आरपीसी है असल में, जिस तरह से "आराम" सामान्य रूप से कार्यान्वित किया जाता है, ...

— masterxilo

213

REST समुदाय में कोई नहीं कहता है कि REST आसान है। HATEOAS उन पहलुओं में से एक है जो एक REST आर्किटेक्चर में कठिनाई जोड़ता है।

लोग आपके द्वारा सुझाए गए सभी कारणों से HATEOAS नहीं करते: यह मुश्किल है। यह सर्वर साइड और क्लाइंट दोनों में जटिलता जोड़ता है (यदि आप वास्तव में इससे लाभ प्राप्त करना चाहते हैं)।

आज, अरबों लोग REST के लाभों का अनुभव करते हैं। क्या आप जानते हैं कि "चेकआउट" URL अमेज़न पर क्या है? मैं नही। फिर भी, मैं हर दिन चेकआउट कर सकता हूं। क्या वह URL बदल गया है? मुझे पता नहीं, मुझे परवाह नहीं है।

क्या आपको पता है परवाह है? जिस किसी ने भी स्क्रीन लिखी है वह अमेज़ॅन स्वचालित ग्राहक को स्क्रैप करता है। किसी को, जिनके पास संभावित रूप से वेब ट्रैफ़िक सूँघने की संभावना है, HTML पेज पढ़ें, आदि यह जानने के लिए कि कब और क्या लोड के साथ क्या कॉल करना है।

और जैसे ही अमेज़ॅन ने अपनी आंतरिक प्रक्रियाओं और URL संरचना को बदल दिया, उन कठिन कोडित क्लाइंट विफल हो गए - क्योंकि लिंक टूट गए।

फिर भी, कैज़ुअल वेब सर्फ़र दिन भर मुश्किल से ही खरीदारी कर पाते थे।

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

सॉफ्टवेयर लिखने वाले अधिकांश लोग ऐसा नहीं करते हैं। स्वचालित क्लाइंट लिखने वाले अधिकांश लोग परवाह नहीं करते हैं। ज्यादातर लोगों को अपने क्लाइंट को ठीक करना आसान लगता है, जब वे इंजीनियर की तुलना में पहले स्थान पर नहीं टूटते हैं। अधिकांश लोगों के पास पर्याप्त ग्राहक नहीं होते हैं जहां यह मायने रखता है।

यदि आप विशेषज्ञ तकनीक समर्थन और यातायात के दोनों किनारों पर आईटी के साथ दो प्रणाली के बीच संवाद करने के लिए एक आंतरिक एपीआई लिख रहे हैं, जो जल्दी, मज़बूती से और परिवर्तन की एक अनुसूची के साथ परिवर्तन संवाद करने में सक्षम हैं, तो REST आपको कुछ नहीं खरीदता है। आपको इसकी आवश्यकता नहीं है, आपका ऐप पर्याप्त बड़ा नहीं है, और यह लंबे समय तक मायने नहीं रखता है।

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

इसलिए, इस तरह के एक ऑपरेशन से HATEOAS को बहुत फायदा होगा, क्योंकि यह आसान है संस्करण के लिए, पुराने क्लाइंट के लिए माइग्रेट करने में आसान, पीछे से संगत नहीं होना आसान है।

एक क्लाइंट जो इसके बारे में बहुत कुछ बताता है, वह सर्वर पर काम करता है, और नतीजों पर काम करने वाले क्लाइंट के सर्वर के बदलावों से ज्यादा मजबूत होता है जो ऐसा नहीं करता है।

लेकिन अधिकांश लोगों को उस लचीलेपन की आवश्यकता नहीं होती है। वे 2 या 3 विभागों के लिए सर्वर कोड लिख रहे हैं, यह सभी आंतरिक उपयोग है। यदि यह टूट जाता है, तो वे इसे ठीक कर देते हैं, और उन्होंने अपने सामान्य ऑपरेशन में यह तथ्य किया है।

लचीलापन, चाहे आरईएसटी या किसी और चीज से, जटिलता को जन्म देती है। यदि आप इसे सरल, और तेज़ चाहते हैं, तो आप इसे लचीला नहीं बनाते हैं, आप "बस करते हैं", और किया जा सकता है। जैसा कि आप सिस्टम में अमूर्तता और डेरेफेरिंग जोड़ते हैं, तो सामान अधिक कठिन हो जाता है, अधिक बॉयलर प्लेट, परीक्षण करने के लिए अधिक कोड।

REST का अधिकांश भाग "आपको इसकी आवश्यकता नहीं है" बुलेट बिंदु विफल हो जाता है। तक, निश्चित रूप से, आप करते हैं।

यदि आपको इसकी आवश्यकता है, तो इसका उपयोग करें, और इसका उपयोग करें जैसे कि इसे बाहर रखा गया है। REST HTTP पर आगे और पीछे सामान नहीं दिखा रहा है। यह कभी नहीं रहा है, यह उससे कहीं अधिक उच्च स्तर है।

लेकिन जब आपको REST की आवश्यकता होती है, और आप REST का उपयोग करते हैं, तो HATEOAS एक आवश्यकता है। यह पैकेज का हिस्सा है, और यह काम करने के लिए महत्वपूर्ण है।

— विल हार्टुंग
स्रोत

11

मुझे ऐसा लगता है कि आपको इस उत्तर के लिए कम से कम एक हज़ार और लाइक चाहिए। ईमानदारी से, मुझे यह कल्पना करना है: 'वास्तविक' होना कितना महत्वपूर्ण है REST प्रश्न काफी सामने आता है। नरक, मैं इस धागे को मिला जब एक आगामी बैठक में उपयोग करने के लिए गोला बारूद के लिए सिर्फ उस कारण के लिए कुछ googling कर रहा था।

— nograde

2

धन्यवाद भगवान (या कोड), कोई HATEOAS के नुकसान के बारे में भी बात कर रहा है!

— इलियाकिल्ली

6

क्या कोई और फायदा है तो आसानी से यूआरएल बदलने की क्षमता? आप सिर्फ नए विकल्प नहीं जोड़ सकते क्योंकि मनुष्यों के विपरीत कार्यक्रम कुछ नया काम नहीं कर सकता है। साथ ही आप केवल URL जानने से लेकर कार्यों के नाम जानने तक स्थानांतरित हो गए हैं।

— जिमी टी।

अगर एपीआई उपभोक्ता को कुछ भी पता नहीं है, तो यह केवल उपयोगकर्ता के कार्यों को 1: 1

— जिमी टी।

2

URL के परिवर्तन के बारे में, यह मत भूलो कि आपका क्लाइंट कैश का उपयोग कर सकता है और इसलिए, आपको पिछले URL को संभालने के लिए सर्वर पर व्यवहार रखना चाहिए (या सिर्फ पुनर्निर्देशित करें)। एपीआई को विकसित करने की किसी भी रणनीति के रूप में, आपको अपने पुराने व्यवहार को काम करते रहना चाहिए। HATEOAS वहाँ बहुत मदद नहीं करता है।

— ब्रूनो कोस्टा

21

हां, मुझे एपीआई में हाइपरमीडिया के साथ कुछ अनुभव हुआ है। यहाँ कुछ लाभ दिए गए हैं:

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

आप इन बुलेट बिंदुओं की गहन व्याख्या यहाँ पा सकते हैं: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

(यहाँ भी इसी तरह का प्रश्न है: /software/149124/what-is-the-benefit-of-hypermedia-hateoas जहाँ मैंने एक ही विवरण दिया है)

— जोर्न वाइल्ड
स्रोत

एक ही सेवा के कई कार्यान्वयन: क्या आप विस्तृत कर सकते हैं? मैं नहीं देखता कि यह कैसे मदद करता है।

— अब्बादोन

मैंने इसे पाठ में समझाने की कोशिश की है। क्या इसने सहायता की?

— जोर्न वाइल्ड

11

रिचर्डसन की परिपक्वता स्तर 3 मूल्यवान है और इसे अपनाया जाना चाहिए। जॉर्न वाइल्ड पहले ही वेल्ट द्वारा कुछ फायदे और एक अन्य जवाब को संक्षेप में बता चुके हैं, इसे बहुत अच्छी तरह से पूरक करते हैं।

हालांकि, रिचर्डसन की परिपक्वता स्तर 3 फील्डिंग के हेटोएएस के समान नहीं है। रिचर्डसन की परिपक्वता स्तर 3 केवल एपीआई डिज़ाइन के बारे में है। फील्डिंग का HATEOAS API डिज़ाइन के बारे में भी है, लेकिन क्लाइंट सॉफ़्टवेयर को भी निर्धारित करता है को यह नहीं चाहिए कि संसाधन में संरचना से परे एक विशिष्ट संरचना होती है जिसे मीडिया प्रकार द्वारा परिभाषित किया जाता है। इसके लिए एक वेब ब्राउज़र की तरह एक बहुत ही सामान्य क्लाइंट की आवश्यकता होती है, जिसे विशिष्ट वेबसाइटों के बारे में जानकारी नहीं होती है। चूंकि रॉय फील्डिंग ने REST शब्द को गढ़ा है और REST के अनुपालन के लिए HATEOAS को एक आवश्यकता के रूप में सेट किया है, तो सवाल यह है कि क्या हम HATEOAS को अपनाना चाहते हैं और यदि नहीं, तो क्या हम अभी भी अपने API को RESTful कह सकते हैं या नहीं? मुझे लगता है हम कर सकते हैं। मुझे समझाने दो।

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

लेकिन ठीक है, हमारा API वास्तव में RESTful है।

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

क्या API को अभी भी Restful कहा जा सकता है? मुझे ऐसा लगता है। यह API की गलती नहीं है कि उसके किसी ग्राहक ने HATEOAS का उल्लंघन किया है।

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

मैंने अपने REST कार्यान्वयन पैटर्न में HATEOAS पर एक अनुभाग शामिल किया है जिसे JAREST कहा जाता है ।

— www.admiraalit.nl
स्रोत

8

हम एक REST स्तर 3 API का निर्माण कर रहे हैं, जहाँ हमारी प्रतिक्रिया HAL-Json में है। HATEOAS फ्रंट और बैक-एंड दोनों के लिए बढ़िया है लेकिन यह चुनौतियों के साथ आता है। हमने HAL-Json रिस्पॉन्स के अंदर ACL को प्रबंधित करने के लिए कुछ अनुकूलन / परिवर्धन किए (जो HAL-JON पैरामीटर को नहीं तोड़ता)।

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

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

HAL-Json का उपयोग करने का एक और फायदा यह है कि यह स्पष्ट है कि प्रतिक्रिया मॉडल कैसा दिखना चाहिए, क्योंकि एक दस्तावेज मानक है जिसका पालन किया जाना चाहिए।

हमारे अनुकूलन में से एक हम एक कार्रवाई आत्म लिंक ऑब्जेक्ट के अंदर आपत्ति कहा कि है कि सामने के छोर को उजागर जो क्रिया या CRUD संचालन प्रमाणीकृत उपयोगकर्ता संबंधित संसाधन पर प्रदर्शन करने के लिए अनुमति दी है ( create:POST, read:GET, update:PUT, edit:PATCH, delete:DELETE)। इस तरह हमारा फ्रंट एंड ACL पूरी तरह से हमारे REST API रिस्पॉन्स से तय होता है, इस जिम्मेदारी को पूरी तरह से बैक-एंड मॉडल पर ले जाता है।

तो एक त्वरित उदाहरण देने के लिए आपके पास HAL-Json में एक पोस्ट ऑब्जेक्ट हो सकता है जो कुछ इस तरह दिखता है:

{
    "_links": {
        "self": {
            "href": "https://hostname/api/v1/posts/1",
            "actions": {
                "read": "GET",
                "update": "PUT",
                "delete": "DELETE"
            }
        }
    },
    "_embedded": {
        "owner": {
            "id": 1,
            "name": "John Doe",
            "email": "john.doe@example.com",
            "_links": {
                "self": {
                    "href": "https://hostname/api/v1/users/1",
                    "actions": {
                        "read": "GET"
                    }
                }
            }
        }
    },
    "subject": "Post subject",
    "body": "Post message body"
}

अब हम सभी को सामने के छोर पर AclServiceएक isAllowedविधि का निर्माण करना है जो यह जाँचता है कि हम जो कार्य करना चाहते हैं वह क्रिया ऑब्जेक्ट में है या नहीं।

वर्तमान में फ्रंट-एंड पर यह उतना ही सरल दिखता है: post.isAllowed('delete');

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

हमारे मामले में हमें यह फायदा है कि हम फ्रंट और बैक-एंड दोनों का निर्माण कर रहे हैं, लेकिन सिद्धांत रूप में इसमें कोई फर्क नहीं होना चाहिए। लेकिन हमारी टीम में एक आम नुकसान यह है कि कुछ डेवलपर्स अपने बैक-एंड मॉडल को बदलकर फ्रंट-एंड मुद्दों (आर्किटेक्चर) को हल करने की कोशिश करते हैं ताकि यह फ्रंट-एंड जरूरतों को "सूट" करे।

— विल्ट
स्रोत

1

बहुत अच्छा जवाब। मुझे लगता है कि ऐसा व्यावहारिक उदाहरण वही था जो मूल प्रश्नकर्ता खोज रहा था।

— www.admiraalit.nl

2

मैंने कुछ वास्तविक परियोजनाओं में HATEOAS का उपयोग किया है, लेकिन रिचर्डसन की तुलना में एक अलग व्याख्या के साथ। अगर ऐसा आपके बॉस चाहते हैं, तो मुझे लगता है कि आपको इसे करना चाहिए। मुझे HATEOAS का मतलब यह है कि आपके संसाधनों में एक HTML सिद्धांत शामिल होना चाहिए, संबंधित संसाधनों के लिए हाइपरलिंक्स और GET के अलावा अन्य क्रियाओं के लिए कार्यक्षमता को उजागर करने के लिए HTML फॉर्म। (यह तब होता है जब एक्सेप्ट टाइप टेक्स्ट / html होता है - अन्य कंटेंट टाइप्स के लिए इन एक्स्ट्रा की आवश्यकता नहीं होती है।) मुझे नहीं पता कि आपके पूरे एप्लिकेशन में सभी रिस्ट रिसोर्सेस को एक साथ लाने का विश्वास कहां से आया है। एक नेटवर्क एप्लिकेशन में कई संसाधन होने चाहिए जो सीधे संबंधित हो सकते हैं या नहीं भी हो सकते हैं। या ऐसा क्यों माना जाता है कि XML, JSON और अन्य प्रकारों को इसका अनुसरण करने की आवश्यकता है। (HATEOAS HTML- विशिष्ट है।)

— क्रिस ब्रॉस्की
स्रोत