मैं डब्ल्यूएडीएल का शोध कर रहा हूं और सोच रहा हूं कि इसे अधिक व्यापक रूप से क्यों नहीं अपनाया जाता है?धीमी गति से WADL क्यों आगे बढ़ता है?
जिस दर पर आरईएसटी उपयोग बढ़ रहा है, मुझे आश्चर्य है कि अधिक विकास प्रयास इसका उपयोग नहीं करते हैं।
क्या इसके डिजाइन में मौलिक दोष है, क्या यह संस्कृति के लिए एक अच्छा मिलान नहीं है जो आम तौर पर रीस्टफुल वेब सेवाओं से घिरा हुआ है, या यह पूरी तरह से कुछ और है?
मुझे लगता है कि WADL लोकप्रियता क्यों नहीं प्राप्त करने का मुख्य कारण यह है कि यह उन सभी समस्याओं को वापस ला सकता है जो हमारे पास SOAP और WSDL के साथ थे। मेरे लिए, इंटरऑपरेबिलिटी पहलू वेब-सेवाओं का एक सबसे महत्वपूर्ण पहलू है।
शुद्ध HTTP मानकों का उपयोग करने के रीस्टफुल तरीके का पालन करके आपको अंतःक्रियाशीलता "मुफ्त में" मिलती है। एक बार जब आपको सेवाओं का वर्णन करने के लिए दस्तावेज़ की आवश्यकता हो, तो अलग-अलग ग्राहक ढांचे (या विभिन्न सर्वर ढांचे) होंगे जो इस दस्तावेज़ को अलग-अलग समझेंगे। एक बार विभिन्न ढांचे WADL से स्वत: जेनरेट कोड आपको फिर से इंटरऑपरेबिलिटी समस्याओं से निपटना होगा।
मानकों की कमी, कमजोर तरीके की कमजोरी और ताकत है, आइए सरल दृष्टिकोण को मौका दें। (भले ही हम वास्तव में आनंद लेने के लिए स्वत: कोड पीढ़ी :-))
"अभ्यास में आराम: हाइपरमीडिया और सिस्टम वास्तुकला" जिम वेबर, Savas Parastatidis, और इयान रॉबिन्सन द्वारा चार चिंताओं का उल्लेख है:
अंक 1 & 2 डायनामिक बनाम स्थिर क्लाइंट बाइंडिंग पर तर्क हैं। WADL का उपयोग करते समय, सेवा कार्यान्वयनकर्ता को सेवा परिवर्तन के रूप में स्कीमा की पिछली संगतता से सावधान रहना होगा। डब्ल्यूएडीएल के बिना, क्लाइंट को लचीला होना चाहिए कि यह प्रतिक्रियाओं को कैसे समझता है।
प्वाइंट 3 कार्य प्रवाह से संबंधित है। डब्ल्यूएडीएल उस ऑर्डर को दस्तावेज नहीं करता है जिसमें एपीआई को कॉल किया जाना चाहिए। WADL और गैर-WADL सेवा प्रतिक्रिया दोनों HATEOAS पैराक्टिस के अनुसार लागू होने पर लिंक के माध्यम से ऑर्डर करने के लिए सुराग प्रदान करते हैं।
प्वाइंट 4 यह मानता है कि HEAD और OPTIONS परिणाम WADL परिभाषा के साथ असंगत हो सकते हैं। प्रैक्टिस में, शायद ही कभी इन तरीकों में से किसी एक को लागू या इस्तेमाल किया जाता है।
कई आरईएसटी कार्यान्वयन त्वरित और गंदे हैं। मेरे उपयोग के लिए केवल एक आरईएसटी सेवा लागू करना आसान है। ऐसा तब होता है जब मुझे एक अलग टीम द्वारा प्रदान की जाने वाली सेवा के लिए क्लाइंट बनाना होता है जिसे मैं दस्तावेज चाहता हूं। अधिक औपचारिक, बेहतर। कोड पढ़ने योग्य दस्तावेज, जैसे कि डब्ल्यूएडीएल, सबसे अच्छा होगा।
एक ग्राहक implementor के रूप में मेरे चिंताएं हैं:
जो लोग सोचते हैं कि लोग इन दिनों "स्वैगर" जैसी चीजों की लोकप्रियता देखते हैं। –
मैं सहमत नहीं हूं कि आरईएसटी का उपयोग करते समय इंटरऑप "मुक्त" है। आरईएसटी जादुई रूप से इंटरऑप प्रदान नहीं करता है, वैसे भी एक डब्ल्यूएडीएल प्रदान करने की उम्मीद नहीं करेगा। मैं पहचानता हूं कि इंटरऑप चुनौतियां हैं (कुछ इसे "प्रतिबाधा मेल नहीं खाते" कहते हैं, जब जावा क्लास में एक्सएसडी, या एक्सएसडी से सी # में मैपिंग करते हैं। लेकिन यह उन सभी मैपिंग दृष्टिकोणों के लिए जरूरी नहीं है। वेब सेवाओं के लिए 80% इंटरऑप केस का समर्थन करने के लिए विशेष रूप से एक्सएसडी अधिक जटिल है। यदि डब्ल्यूएडीएल अपने लक्ष्यों में उचित रूप से मामूली है, तो यह नुकसान के कम जोखिम के साथ वास्तविक मूल्य प्रदान कर सकता है। – Cheeso
मैं चीसो से सहमत हूं, आरईएसटी कुछ भी मुफ्त में उपलब्ध नहीं कराती है। यह सुनिश्चित करने के लिए अभी भी 'कुछ काम' है कि आप विशेष रूप से डेटा पेलोड के साथ सेब (और नारंगी नहीं) से निपट रहे हैं (चाहे HTTP है या नहीं)। आरईएसटी विभिन्न 'भाषाओं/टूल-सेट' लक्ष्यों पर मैप करते समय भी मुद्दों को लागू करता है। यह दो अंतराल के बीच प्रतिबाधा विसंगति के लिए और भी अवसर प्रदान करता है (विशेष रूप से जब प्रत्येक समापन बिंदु नियंत्रण के एक बिंदु के नीचे नहीं होते हैं)। – gto406
मुझे नहीं लगता कि यह कम अनुकूलन के पीछे कारण है (वास्तव में मैं इस कारण की वैधता पर भी बहस कर सकता हूं, इसके अलावा)। मेरी समझ में wadl के कम अनुकूलन का कारण होगा, यह पूरे समाधान की वास्तुकला में उपयोग करें। बहुत कम लोग एक साथ आरईएसटी और एंटरप्राइज़ एसओए सोचते हैं। आरईएसटी सेवाओं को प्रायः जावास्क्रिप्ट या मोबाइल ऐप के उपभोग के लिए फ्रंटेंड पर रखा जाता है। माइक्रो सर्विसेज एसओए आर्किटेक्चर में आरईएसटी का अनुकूलन छोटा है लेकिन बढ़ रहा है, यह डब्ल्यूएडीएल और ऑटो क्लाइंट पीढ़ी जैसी चीजों के लिए दबाव डालेगा। –