संयुक्तता और HATEOAS

Question

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

/collection1 
collection1 
    |-sub1 
    |-sub1sub1 
|-sub1sub1sub1 
     |-sub1sub1sub1sub1 
    |-sub1sub2 
    |-sub2 
    |-sub2sub1 
    |-sub2sub2 
    |-sub3 
    |-sub3sub1 
    |-sub3sub2 

अगर हम का पालन करें: मैं इस दृष्टिकोण से लाभ (decoupled ग्राहकों) लेकिन मेरे लिए नकारात्मक पक्ष यह ग्राहक लिंक हर बार पहुँच कुछ यानी संसाधनों का निम्न पदानुक्रम दिया की कोशिश करता है की खोज करने की जरूरत है समझते हैं दृष्टिकोण "ग्राहक केवल रूट यूआरआई जानने की जरूरत", तो एक ग्राहक केवल ऊपर यूआरआई यानी/collection1 जड़ और यूआरआई के बाकी के बारे में पता हाइपरमीडिया लिंक के माध्यम से ग्राहकों द्वारा की खोज की जानी चाहिए होगा। मुझे यह बोझिल लगता है क्योंकि प्रत्येक बार जब ग्राहक को GET करने की आवश्यकता होती है, तो sub1sub1sub1sub1 पर कहें, क्लाइंट को पहले GET/संग्रह 1 पर जाना चाहिए और लौटा प्रतिनिधित्व में परिभाषित अनुवर्ती लिंक और फिर उप संसाधनों पर पहुंचने के लिए कई और GETs करें वांछित संसाधन? या जुड़ाव के बारे में मेरी समझ पूरी तरह से गलत है?

सादर, सुरेश

Answer 1

जब आप कोशिश करते हैं और एक REST API कि उपयोगकर्ता एजेंट है कि एपीआई लेने वाली है के प्रवाह से मेल नहीं खाता निर्माण आप इस बेमेल में चलेंगे।

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

आप कोशिश करते हैं और लिंक किए गए डेटा भंडार के कुछ प्रकार के और संक्रमण के एक स्वतंत्र सेट के रूप में अपने ग्राहक यूआई के रूप में अपने REST API का मॉडल है तो आप HATEOAS काफी दर्द मिल जाएगा।

Answer 2

मुझे नहीं लगता कि कि सख्त आवश्यकता है है। मैं इसे कैसे समझता हूं, क्लाइंट के लिए सीधे संसाधनों का उपयोग करना और वहां से शुरू करना कानूनी है। महत्वपूर्ण बात यह है कि आप राज्य संक्रमणों के लिए ऐसा नहीं करते हैं, यानी/foo1 पर आगे बढ़ने के बाद स्वचालित रूप से/foo2 के साथ आगे बढ़ें नहीं। इसे संपादित करने के लिए प्रारंभ में/उत्पादों/1234 को पुनर्प्राप्त करना बिल्कुल ठीक लगता है। सर्वर हमेशा पीछे की ओर संगत रहने के लिए/दुकान/उत्पादों/1234 पर एक रीडायरेक्ट वापस कर सकता है (जो खोज इंजन, बुकमार्क और बाहरी लिंक के लिए भी वांछनीय है)।

Answer 3

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

विचार करें कि एक वेब ब्राउज़र कैसे अपने बुकमार्क रखता है। आपके पास ब्राउज़र में शायद दस या सौ बुकमार्क हो सकते हैं, और संभवतः आप पृष्ठों में पदानुक्रम में इन गहरे में से कुछ पाएंगे, लेकिन ब्राउज़र उन्हें उनको ढूंढने के लिए आवश्यक पथ को याद किए बिना कर्तव्यपूर्वक याद करता है।

एक अधिक समृद्ध क्लाइंट एप्लिकेशन sub1sub1sub1sub1 के यूआरआई को याद कर सकता है और यदि यह अभी भी काम करता है तो इसका पुन: उपयोग कर सकता है। यह संभावना है कि यह अभी भी एक ही चीज़ का प्रतिनिधित्व करता है (इसे करना चाहिए)। यदि यह अब मौजूद नहीं है या किसी अन्य ग्राहक कारण (4xx) के लिए विफल रहता है तो आप यह देखने के लिए अपने कदम उठा सकते हैं कि आप एक उपयुक्त प्रतिस्थापन पा सकते हैं या नहीं।

और निश्चित रूप से डेरेल मिलर कहते हैं क्या :-)