HATEOAS आपकी URL संरचना को अधिक या कम आज़ादी से बदलने की क्षमता के अलावा खोज और अवनति के लिए क्या प्रदान करता है?

Question

हाल ही में मैं हाइपरमेडिया के बारे में एप्लीकेशन स्टेट (HATEOAS) के इंजन के रूप में पढ़ रहा हूं, एक वेब एपीआई को "सही मायने में RESTful" बनाने का दावा करने वाली बाधा। यह मूल रूप से उबलता है जिसमें वर्तमान स्थिति से आपके द्वारा किए जा सकने वाले संभावित बदलावों की हर प्रतिक्रिया के लिंक शामिल हैं।

मुझे यह समझाइए कि मेरी समझ के आधार पर HATEOAS क्या है - और अगर मैंने कुछ याद किया तो कृपया मुझे सही करें।

/
    GET: {
        "_links": {
            "child": [
                { "href": "http://myapi.com/articles", "title": "articles" }
            ]
        }
    }

/articles?contains=HATEOAS
    GET: {
        "_items": [
            { "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" },
            { "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" }
        ],
        "_links": {
            "self": { "href": "http://myapi.com/articles", "title": "articles" },
            "parent": { "href": "http://myapi.com/", "title": "home" }
        }
    }

    POST: {
        "title": "A New Article",
        "body": "Article body",
        "tags": [ "tag1", "tag2" ]
    }

/articles/0
    GET: {
        "title": "Why Should I Care About HATEOAS?",
        "body": "Blah blah blah"
        "tags": [ "REST", "HATEOAS" ],
        "_links": {
            "self": { "href": "http://myapi.com/articles/0", "title": "article" },
            "parent": { "href": "http://myapi.com/articles", "title": "articles" }
        }
    }

HATEOAS को दो प्रमुख लाभ प्रदान करने का दावा किया जाता है:

1. संपूर्ण सेवा खोज योग्य प्रारंभिक रूप है मूल URI, दस्तावेज़ीकरण की अब आवश्यकता नहीं है।

2. क्लाइंट को उस सर्वर से हटा दिया जाता है जो अब URI संरचना को स्वतंत्र रूप से बदल सकता है। यह एपीआई संस्करण की आवश्यकता को समाप्त करता है।

लेकिन मेरे विचार में, एक सेवा अपनी यूआरआई संरचना से बहुत अधिक है। इसे प्रभावी ढंग से उपयोग करने के लिए, आपको यह भी जानना होगा:

• आप किस क्वेरी पैरामीटर का उपयोग कर सकते हैं और उनके संभावित मान
• JSON / XML / आपके दस्तावेज़ों को आपके POST / PATCH / etc अनुरोधों में भेजने की आवश्यकता है
• सर्वर द्वारा भेजे गए प्रतिक्रिया की संरचना
• संभावित त्रुटियां जो हो सकती हैं
• ...

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

इसका एकमात्र लाभ यह है कि आप अपने URL ढांचे को कम या ज्यादा स्वतंत्र रूप से बदल सकते हैं (वैसे, सिद्धांत "कूल यूआरआईज़ नहीं बदलते हैं ? " ) क्या हुआ । क्या मेरी समझ सही है?

Answer 1

मुझे लगता है कि आपकी प्रवृत्ति काफी हद तक सही है; उन घोषित लाभ वास्तव में यह सब महान नहीं हैं, जैसे कि किसी भी गैर-तुच्छ वेब अनुप्रयोग के लिए ग्राहकों को इस बात का ध्यान रखना होगा कि वे सिंटैक्स के साथ-साथ क्या कर रहे हैं।

लेकिन इसका मतलब यह नहीं है कि आप अपने आवेदन HATEOAS के सिद्धांतों का पालन नहीं करना चाहिए!

HATEOAS का वास्तव में क्या मतलब है? इसका मतलब है कि आपके एप्लिकेशन को संरचित करना ताकि यह एक वेब साइट की तरह सिद्धांत रूप में हो , और यह कि वे सभी ऑपरेशन जो आप करना चाहते हैं, उन्हें कुछ जटिल स्कीमा डाउनलोड किए बिना खोजा जा सकता है। (परिष्कृत WSDL स्कीमा सब कुछ कवर कर सकते हैं, लेकिन जब तक वे करते हैं, तब तक वे लगभग हर प्रोग्रामर की क्षमता को कभी भी समझने की क्षमता से अधिक हो जाते हैं, अकेले लिखते हैं! आप इस तरह की जटिलता के खिलाफ प्रतिक्रिया के रूप में HATEOAS देख सकते हैं।)

HATEOAS का मतलब सिर्फ अमीर लिंक नहीं है। इसका मतलब है कि HTTP मानक के त्रुटि तंत्र का उपयोग करके यह इंगित करना कि वास्तव में क्या गलत हुआ; आपको सिर्फ "वाह" के साथ जवाब देने की ज़रूरत नहीं है! नहीं ”और इसके बजाय यह बताने के लिए कि वास्तव में गलत क्या था और ग्राहक इसके बारे में क्या कर सकता है, एक दस्तावेज प्रदान कर सकता है। इसका अर्थ ऑप्शन रिक्वेस्ट जैसी चीजों का समर्थन करने का भी है (ग्राहकों को यह पता लगाने का मानक तरीका कि वे HTTP विधियों का उपयोग क्या कर सकते हैं) और सामग्री प्रकार की बातचीत, ताकि प्रतिक्रिया के प्रारूप को एक ऐसे रूप में अनुकूलित किया जा सके जिसे ग्राहक संभाल सकें। इसका अर्थ है व्याख्यात्मक पाठ में डालना(या, अधिक संभावना है, इसके लिए लिंक) ताकि ग्राहक यह देख सकें कि गैर-तुच्छ मामलों में सिस्टम का उपयोग कैसे करें यदि वे नहीं जानते हैं; व्याख्यात्मक पाठ मानव पठनीय हो सकता है या यह मशीन पठनीय हो सकता है (और जैसा आप चाहें उतना जटिल हो सकता है)। अंत में, इसका मतलब है कि ग्राहक लिंक (क्वेरी मापदंडों को छोड़कर) को संश्लेषित नहीं करते हैं ; क्लाइंट केवल एक लिंक का उपयोग करेंगे यदि आपने उन्हें यह बताया था।

आपको साइट को उपयोगकर्ता द्वारा ब्राउज़ किए जाने के बारे में सोचना होगा (जो HTML के बजाय JSON या XML पढ़ सकते हैं, इसलिए थोड़ा अजीब है) लिंक के लिए एक महान मेमोरी और HTTP मानकों के एक ज्ञानवर्धक ज्ञान के साथ, लेकिन अन्यथा क्या होगा का कोई ज्ञान नहीं है करना।

और हां, आप HTML (5) / जेएस क्लाइंट की सेवा के लिए सामग्री प्रकार की बातचीत का उपयोग कर सकते हैं जो उन्हें आपके एप्लिकेशन का उपयोग करने देगा, यदि उनका ब्राउज़र स्वीकार करने के लिए तैयार है। आखिरकार, अगर आपका RESTful API कोई अच्छा है, तो उसके शीर्ष पर लागू करने के लिए "तुच्छ" होना चाहिए?

Answer 2

चीजें हैं, HATEOAS को एक दूसरे स्तंभ के साथ आना चाहिए जो परिभाषित करता है कि RESTful API क्या है: मानकीकृत मीडिया प्रकार। रॉय ने खुद फील्डिंग की

REST API को संसाधनों का प्रतिनिधित्व करने के लिए उपयोग किए जाने वाले मीडिया प्रकारों को परिभाषित करने में अपने लगभग सभी वर्णनात्मक प्रयासों को खर्च करना चाहिए।

एक मानकीकृत मीडिया प्रकार के साथ, जो एक दूसरे से संसाधन को इंगित करने के लिए स्पष्ट रूप से संक्रमण, और हाइपरटेक्स्ट को परिभाषित करते हैं, आप एक संसाधन ग्राफ़ बना सकते हैं जो किसी भी क्लाइंट को तोड़े बिना किसी भी रूप ले सकता है। वेब काम की तरह, वास्तव में: आपके पास दस्तावेज़ के बीच लिंक है, और दस्तावेज़ HTML में लिखे गए हैं जो परिभाषित करते हैं कि उन लिंक का पालन कैसे करें। <a href>एक GET है, <form>GET या POST है (और GET के मामले में उपयोग करने के लिए url टेम्पलेट को परिभाषित करें), <link type="text/css">GET है ... आदि यह है कि कैसे ब्राउज़र मनमाने ढंग से संरचित HTML पृष्ठ और वेब पर नेविगेट कर सकते हैं।

आपके द्वारा किए गए सभी बिंदु

• आप किस क्वेरी पैरामीटर का उपयोग कर सकते हैं और उनके संभावित मान
• JSON / XML / आपके दस्तावेज़ों को आपके POST / PATCH / etc अनुरोधों में भेजने की आवश्यकता है
• सर्वर द्वारा भेजे गए प्रतिक्रिया की संरचना
• संभावित त्रुटियां जो हो सकती हैं

ऐसे बिंदु हैं जो आपको मानकीकृत मीडिया प्रकार की परिभाषा से प्रभावित होने चाहिए । बेशक, यह बहुत कठिन है, और कुछ ऐसा नहीं है जो ज्यादातर लोग सोचते हैं कि जब वे "रीस्ट" एपीआई को परिभाषित करते हैं। आप केवल व्यावसायिक संस्थाओं को नहीं ले सकते और एक RESTful API के लिए JSON दस्तावेज़ में अपनी विशेषताओं को हटा सकते हैं।

बेशक, जो हुआ है वह यह है कि REST को किसी तरह "जटिल SOAPy चीज़ के बजाय HTTP का उपयोग करने" का मतलब मिला। बस HTTP और HyperText का उपयोग करना Restful होने के लिए पर्याप्त नहीं है, यह वही है जो ज्यादातर लोग गलत करते हैं।

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

आगे की पढाई

• http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
• http://martinfowler.com/articles/richardsonMaturityModel.html

आशा है कि यह मदद थोड़ी स्पष्ट कर देगी :)

Answer 3

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

यहाँ एक उदाहरण सायरन दस्तावेज़ है:

{
  "class": [ "order" ],
  "properties": { 
      "orderNumber": 42, 
      "itemCount": 3,
      "status": "pending"
  },
  "entities": [
    {
      "class": [ "info", "customer" ],
      "rel": [ "http://x.io/rels/customer" ], 
      "properties": { 
        "customerId": "pj123",
        "name": "Peter Joseph"
      },
      "links": [
        { "rel": [ "self" ], "href": "http://api.x.io/customers/pj123" }
      ]
    }
  ],
  "actions": [
    {
      "name": "add-item",
      "title": "Add Item",
      "method": "POST",
      "href": "http://api.x.io/orders/42/items",
      "type": "application/x-www-form-urlencoded",
      "fields": [
        { "name": "orderNumber", "type": "hidden", "value": "42" },
        { "name": "productCode", "type": "text" },
        { "name": "quantity", "type": "number" }
      ]
    }
  ],
  "links": [
    { "rel": [ "self" ], "href": "http://api.x.io/orders/42" },
    { "rel": [ "previous" ], "href": "http://api.x.io/orders/41" },
    { "rel": [ "next" ], "href": "http://api.x.io/orders/43" }
  ]
}

जैसा कि आप देख सकते हैं, संबंधित कॉल करने के तरीके के बारे में जानकारी actionsसंदेश में दी गई है, और फिर इस जानकारी की व्याख्या करने से, ग्राहक बदलने के लिए अधिक प्रतिरोधी हो जाता है।

यह विशेष रूप से शक्तिशाली हो जाता है यदि rels URI हैं जिन्हें एक निश्चित शब्दावली से नहीं बल्कि देखा जा सकता है।

Answer 4

आपने कहां पढ़ा कि HATEAOS सेवाओं के लिए "प्रलेखन की अब कोई आवश्यकता नहीं है"? जैसा कि आप कहते हैं, आपको अभी भी लिंक के शब्दार्थों का दस्तावेजीकरण करना होगा। हालाँकि, HATEOAS के साथ आपको दस्तावेज़ की आवश्यकता नहीं है, और इसलिए हमेशा के लिए, अधिकांश URI की संरचना।

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

Comments

एक जगह जहां कोई यह पढ़ सकता है कि "प्रलेखन की अब आवश्यकता नहीं है" रॉय फील्डिंग का शोध प्रबंध है, जिसने इस शब्द को गढ़ा।

— मेरिटॉन - हड़ताल पर

मैंने सिर्फ "प्रलेखन" के उपयोग के लिए फील्डिंग के शोध प्रबंध को खोजा और पाया कि "दस्तावेज की अब आवश्यकता नहीं है" कथन के समान कुछ भी नहीं है। क्या आप कृपया बता सकते हैं कि फील्डिंग के शोध प्रबंध में आपको यह दावा कहां से मिला?

— जोनाथन गिद्दी

Answer 5

(HATEOAS), बाधा जो एक वेब एपीआई "वास्तव में RESTful" बनाने का दावा किया जाता है

केवल एक चीज जो इसे सच्चा REST API बनाती है वह सभी बाधाओं को पूरा कर रही है, केवल एक ही नहीं।

लेकिन मेरे विचार में, एक सेवा अपनी यूआरआई संरचना से बहुत अधिक है। इसे प्रभावी ढंग से उपयोग करने के लिए, आपको यह भी जानना होगा: ...

इसलिए हमें अन्य बाधाओं, स्व-वर्णनात्मक संदेश, आदि की आवश्यकता है ...

ब्रेकिंग क्लाइंट से बचने के लिए, आपको अभी भी अपना एपीआई संस्करण बनाना होगा।

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