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




hateoas (4)

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

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

तुम क्या सोचते हो? क्या आपको असली दुनिया परियोजना में हैटओएएस के साथ कोई अनुभव है?


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

  1. अन्वेषण एपीआई: यह मामूली लग सकता है लेकिन एक अन्वेषण एपीआई की शक्ति को कम मत समझना। डेटा के चारों ओर ब्राउज़ करने की क्षमता क्लाइंट डेवलपर्स के लिए एपीआई और उसके डेटा संरचनाओं का एक मानसिक मॉडल बनाने के लिए बहुत आसान बनाता है।

  2. इनलाइन दस्तावेज: लिंक संबंधों के रूप में यूआरएल का उपयोग क्लाइंट डेवलपर्स को दस्तावेज़ीकरण के लिए इंगित कर सकता है।

  3. सरल ग्राहक तर्क: एक क्लाइंट जो स्वयं को बनाने के बजाय यूआरएल का पालन करता है, को लागू करना और बनाए रखना आसान होना चाहिए।

  4. सर्वर यूआरएल संरचनाओं का स्वामित्व लेता है: हाइपर्मियाडिया का उपयोग सर्वर द्वारा उपयोग की जाने वाली यूआरएल संरचनाओं के क्लाइंट के हार्ड कोडित ज्ञान को हटा देता है।

  5. अन्य सेवाओं को सामग्री लोड करना बंद करें: हाइपरमीडिया आवश्यक है जब अन्य सर्वरों को सामग्री लोड करना (उदाहरण के लिए एक सीडीएन)।

  6. लिंक के साथ संस्करण: Hypermedia एपीआई के संस्करणांकन में मदद करता है।

  7. एक ही सेवा के कई कार्यान्वयन: हाइपरमीडिया एक आवश्यकता है जब एक ही सेवा के कई कार्यान्वयन मौजूद हैं (और एक ग्राहक को उनमें से एक से अधिक तक पहुंचने की आवश्यकता है)।

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

(यहां एक समान प्रश्न है: https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas जहां मैंने एक ही स्पष्टीकरण दिया है)


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


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

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

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

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

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

फिर भी, आकस्मिक वेब सर्फर पूरे दिन खरीदारी करने में सक्षम थे, शायद ही कभी एक झटका लगा।

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

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

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

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

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

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

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

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

आरईएसटी का अधिकांश हिस्सा "बुलेट प्वाइंट" की आवश्यकता नहीं है। बेशक, आप करते हैं।

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

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


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

हैटओएएस न केवल एप्लिकेशन के सर्वर-साइड पर एक बाधा डालता है, बल्कि क्लाइंट-साइड पर भी। क्लाइंट को यह नहीं मानना ​​चाहिए कि संसाधन के पास मीडिया प्रकार द्वारा परिभाषित संरचना से परे एक विशिष्ट संरचना है। सर्वर को ऐसे एपीआई की पेशकश करनी चाहिए जो ऐसे क्लाइंट का समर्थन करे।

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

लेकिन ठीक है, हमारी एपीआई वास्तव में भरोसेमंद है।

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

क्या एपीआई अभी भी रीस्टफुल कहा जा सकता है? मुझे ऐसा लगता है। यह एपीआई की गलती नहीं है कि इसके ग्राहकों में से एक ने हेटोआस का उल्लंघन किया है।

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

मैंने जेएआरईटी नामक अपने आरईएसटी कार्यान्वयन पैटर्न में हैटओएएस पर एक सेक्शन शामिल किया है।





hateoas