rest - हेटोआस: पूर्ण या सापेक्ष यूआरएल?




hateoas (6)

HATEOAS का उपयोग कर एक रीस्टफुल वेब सेवा डिज़ाइन करने में, एक संपूर्ण यूआरएल (" http://server:port/application/customers/1234 ") बनाम लिंक के रूप में एक लिंक दिखाने के पेशेवर और विपक्ष क्या हैं। बस पथ ("/ application / ग्राहकों / 1234 ")?


आपके एप्लिकेशन स्केल के रूप में, आप भार संतुलन, असफल, आदि करना चाह सकते हैं। यदि आप पूर्ण यूआरआई वापस करते हैं तो आपके क्लाइंट-साइड ऐप्स सर्वर की आपकी विकसित कॉन्फ़िगरेशन का पालन करेंगे।


आपको हमेशा पूर्ण यूआरएल का उपयोग करना चाहिए। यह संसाधन के लिए अद्वितीय पहचानकर्ता के रूप में कार्य करता है क्योंकि यूआरएल सभी अद्वितीय होने की आवश्यकता है।

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


जब लोग "रिश्तेदार यूरी" कहते हैं तो एक सूक्ष्म वैचारिक अस्पष्टता होती है।

आरएफसी 3 9 86 की परिभाषा के अनुसार , एक सामान्य यूरी में शामिल हैं:

  URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

  hier-part   = "//" authority path-abempty
              / path-absolute
              / path-rootless
              / path-empty

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

मुश्किल बात यह है कि, जब योजना और प्राधिकरण छोड़ा जाता है, तो "पथ" भाग स्वयं या तो एक पूर्ण पथ ("/" से शुरू होता है) या "रूटलेस" सापेक्ष पथ हो सकता है। उदाहरण:

  1. एक पूर्ण यूरी या पूर्ण यूरी: "http://example.com:8042/over/there?name=ferret"
  2. और यह एक सापेक्ष यूरी है, पूर्ण पथ के साथ : "/ over / there"
  3. और यह एक सापेक्ष यूरी है, सापेक्ष पथ के साथ : "यहां" या "./here" या "../here" या आदि

इसलिए, यदि सवाल "क्या सर्वर को आराम से प्रतिक्रिया में सापेक्ष पथ उत्पन्न करना चाहिए", तो जवाब "नहीं" है और यहां विस्तार का कारण उपलब्ध है । मुझे लगता है कि "रिश्तेदार यूरी" के खिलाफ ज्यादातर लोग (मुझे शामिल करें) वास्तव में "सापेक्ष पथ" के खिलाफ हैं।

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

एक ओर, मुझे अभी भी लगता है कि एक पूर्ण यूरी लौटने वाले सर्वर की सिफारिश की जाती है। हालांकि, सर्वर को मेजबाननाम को कभी भी हार्डकोड नहीं करना चाहिए : इस तरह स्रोत कोड के अंदर पोर्ट चीज (अन्यथा मैं पूर्ण पथ के साथ सापेक्ष uri के लिए फ़ॉलबैक करूंगा)। समाधान हमेशा सर्वर अनुरोध के HTTP होस्ट के "होस्ट" हेडर से उपसर्ग प्राप्त कर रहा है। सुनिश्चित नहीं है कि यह हर परिस्थितियों के लिए काम करता है या नहीं।

दूसरी तरफ, क्लाइंट के लिए "http://example.com:8042" और पूर्ण पथ को जोड़ना बहुत मुश्किल नहीं लगता है। आखिरकार, ग्राहक पहले से ही उस योजना और डोमेन नाम को जानता है जब यह सर्वर से अनुरोध भेजता है?

सब कुछ, मैं कहूंगा, निरपेक्ष यूरी का उपयोग करने की अनुशंसा करता हूं, संभवतः पूर्ण पथ के साथ रिश्तेदार यूरी में फॉलबैक, सापेक्ष पथ का कभी भी उपयोग न करें


बड़े एपीआई परिणामों में एक महत्वपूर्ण विचार बार-बार पूर्ण यूआरआई सहित अतिरिक्त नेटवर्क ओवरहेड है। मानो या नहीं, gzip पूरी तरह से इस मुद्दे को हल नहीं करता है (यकीन नहीं क्यों)। हम इस बात पर चौंक गए कि परिणामस्वरूप सैकड़ों लिंक शामिल होने पर पूर्ण यूआरआई कितनी जगह ले ली।


पूर्ण यूआरआई का उपयोग करने में एक कमी यह है कि एपीआई को प्रॉक्सी नहीं किया जा सकता है।

इसे वापस ले लो ... सच नहीं है। आपको डोमेन सहित एक पूर्ण यूआरएल के लिए जाना चाहिए।


RayLou की trichotomy का उपयोग कर मेरे संगठन ने पक्षपात (2) का चयन किया है। प्राथमिक कारण XSS (क्रॉस-साइट स्क्रिप्टिंग) हमलों से बचने के लिए है। मुद्दा यह है कि, अगर कोई हमलावर सर्वर से वापस आने वाली प्रतिक्रिया में अपना यूआरएल रूट इंजेक्ट कर सकता है, तो बाद के उपयोगकर्ता अनुरोध (जैसे उपयोगकर्ता नाम और पासवर्ड के साथ प्रमाणीकरण अनुरोध) हमलावर के अपने सर्वर * को अग्रेषित किया जा सकता है।

कुछ ने भार संतुलन के लिए अन्य सर्वरों के अनुरोधों को पुनर्निर्देशित करने में सक्षम होने का मुद्दा सामने लाया है, लेकिन (जबकि यह विशेषज्ञता का मेरा क्षेत्र नहीं है) मैं डरता हूं कि ग्राहकों को स्पष्ट रूप से अलग-अलग रीडायरेक्ट किए बिना लोड संतुलन को सक्षम करने के बेहतर तरीके हैं मेजबान।

* अगर तर्क की इस पंक्ति में कोई दोष है तो कृपया मुझे बताएं। लक्ष्य, निश्चित रूप से, सभी हमलों को रोकने के लिए नहीं है, लेकिन कम से कम एक हमले का एक तरीका है।





hateoas