मैं आरईएसटी कार्यान्वयन में जल्दी हूं और हाल ही में सीखा है कि हम कक्षा कार्यान्वयन के बजाए हमारे जावा सेवा इंटरफेस पर हमारी जेएक्स-आरएस एनोटेशन डाल सकते हैं।जेएक्स-आरएस एनोटेशन: इंटरफेस या कक्षाओं को बेहतर रखना?
मेरे लिए ऐसा लगता है कि इसका परिणाम एक स्वच्छ वर्ग फ़ाइल में हो सकता है, लेकिन इसके परिणामस्वरूप डेवलपर्स को फ़ाइलों के बीच लगातार गड़बड़ करनी पड़ सकती है।
प्रत्येक दृष्टिकोण के पेशेवर और विपक्ष क्या हैं?
आपको इसे एक इंटरफेस में रखना चाहिए। इसके बजाय, मेरे अभ्यास के लिए मुझे इसे एक इंटरफ़ेस में रखना आवश्यक है, क्योंकि मेरा क्लाइंट और सर्वर पक्ष समान जैक्स-आरएस परिभाषा साझा कर रहे हैं।
मैं आरईएसटी-आरपीसी के लिए जैक्स-आरएस का उपयोग करने के इच्छुक हूं।
आरईएसटी का कारण वेब सेवा यूआरएल एपीआई को किसी भी प्रोग्रामिंग ढांचे द्वारा सेवा योग्य और "क्लाइंटेबल" होने की अनुमति देना है।
जैक्स-आरएस का उपयोग हमें सर्वर के पक्ष में जावा का उपयोग करने के लिए प्रतिबंधित करता है।
आरईएसटी-आरपीसी के लिए जैक्स-आरएस का उपयोग हमें सर्वर और क्लाइंट दोनों पक्षों पर जावा का उपयोग करने के लिए प्रतिबंधित करता है।
आरईएसटी-आरपीसी क्या है?
स्पष्टीकरण के एक बहुत ही ठोस दृष्टिकोण में, आरपीसी क्लाइंट पर फ़ंक्शन/विधि को कॉल करने का एक तरीका है, जो सर्वर पर तार पर भेजे जाने पर सर्वर की सेवा की जाती है जैसे कि सर्वर की तरफ एक ही फ़ंक्शन/विधि मौजूद है ।
RestEasy आपको क्लाइंट-साइड पर जाक्स-आरएस परिभाषा का उपयोग सर्वर पक्ष पर सेवा के समान कार्य को कॉल करने की अनुमति देता है।
RestyGWT भी, कॉलबैक विधि निर्दिष्ट करने के लिए इंटरफ़ेस में कुछ संशोधन के साथ आपको क्लाइंट और सर्वर दोनों पक्षों पर जैक्स-आरएस परिभाषा का उपयोग करने की अनुमति देगा। आपको वापसी प्रकार को कॉलबैक विधि के प्रकार तर्क में स्थानांतरित करने के लिए बस एक स्क्रिप्ट लिखनी होगी।
आप सवाल कर सकते हैं कि क्यों दोनों पक्षों पर जावा करने के लिए खुद को प्रतिबंधित करें? क्या वह आरईएसटी के जीवन में किसी एक उद्देश्य को पराजित नहीं करेगा? मुझे लगता है कि जैक्स-आरएस आरईएसटी-आरपीसी एक जैक्स-आरएस सेवा को लागू करने और परीक्षण करने का एक सुविधाजनक मार्ग है। यदि आप एक जैक्स-आरएस सेवा को कार्यान्वित करना चाहते हैं, तो संभवतः आप शुरुआत में जावा में दोनों पक्षों पर ऐसा करेंगे। और फिर जब आपकी सेवा जमीन से निकलती है, तो आप PHP या पायथन क्लाइंट लिखना शुरू कर सकते हैं।
इंटरफ़ेस फ़ाइलों में अपने जैक्स-आरएस लिखना आपको क्लाइंट साइड ऑपरेशंस के लिए अपना इंटरफ़ेस प्रकाशित करने की अनुमति देगा। यह आरईएसटी-आरपीसी के लिए विशेष रूप से सच है। हालांकि, आप गैर-जावा प्रोग्रामर को अपनी वेब सेवा एपीआई प्रकाशित करने के लिए अपनी जैक्स-आरएस परिभाषा पर उत्साहित हो सकते हैं।
मेरे पास इस विषय पर कुछ चल रहा है ... http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html।
मुझे लगता है कि मुझे यहां सम्मानित रूप से धन्य गीक से आंशिक रूप से असहमत होना है। उल्लेख किया गया है कि एक बहुत ही विशिष्ट उपयोग केस है जिसके लिए इंटरफ़ेस पर एनोटेशन के उपयोग की आवश्यकता होती है।
अपने अनुभव में, मुझे ऐसे मामलों का सामना करना पड़ा है जहां डिजाइन या बग द्वारा ढांचा इंटरफ़ेस पर एनोटेशन रखने के लिए ठीक से प्रतिक्रिया नहीं देता है। उदाहरण के लिए, जब आप इंटरफ़ेस पर एनोटेशन डालते हैं तो Apache CXF पथ में परिभाषित @PathParams के साथ @PUT अनुरोधों को सही तरीके से संसाधित नहीं करता है। मुझसे मत पूछो क्यों।सीएक्सएफ इस में अकेला नहीं है; स्प्रिंग सुरक्षा इंटरफेस पर एनोटेशन रखने में समान सीमाओं से ग्रस्त है। तो यह ऊपर वर्णित एक के लिए एक counterpoint है।
ऐसे मामलों में जहां आप एनोटेशन कहां रखना है, पर विचार करने के लिए स्वतंत्र हैं, मैं आपको इस बात पर विचार करने के लिए आग्रह करता हूं कि इरादे, डिजाइन और विकास की आसानी से क्या समझ में आता है।
दार्शनिक तर्क के रूप में, कुछ लोग कहते हैं कि इंटरफेस पर एनोटेशन रखना अनुबंध प्रोग्रामिंग का एक और रूप है- आप कह रहे हैं कि कार्यान्वयन कुछ नियमों का पालन करेगा।
उस सिक्का का दूसरा पक्ष (इंटरफेस की आपकी परिभाषा के आधार पर) यह है कि इंटरफेस को इस बात की परवाह नहीं करनी चाहिए कि उनके कार्यान्वयनकर्ताओं ने विधि अनुबंध में परिभाषित लक्ष्य को प्राप्त करने में क्या कदम उठाए हैं। उदाहरण के लिए, जब आप दो कार्यान्वयन हो सकते हैं, तो इंटरफ़ेस पर @ ट्रांसेक्शनल एनोटेशन क्यों रखें, जिसमें से कोई नहीं जानता कि "लेनदेन" क्या हो सकता है?
प्रैक्टिस में, रेखाएं धुंधली होती हैं। एक आरामदायक एंडपॉइंट को परिभाषित करने के मामले में, आप इंटरफेस पर उचित एनोटेशन रखना पसंद कर सकते हैं। मुझे लगता है कि ज्यादातर मामलों में यह समझ में आता है; आपके पास शायद कई कार्यान्वयन नहीं होंगे जहां एक ही विधि हस्ताक्षर विभिन्न HTTP क्रियाओं का जवाब देता है। हालांकि आप ऐसी स्थिति के साथ आ सकते हैं जहां विभिन्न कार्यान्वयन विभिन्न मीडिया प्रकारों का उपभोग और उत्पादन करना पसंद करते हैं।
तो, यहां बड़ा विचार "यह निर्भर करता है।" लेकिन उम्मीद है कि यह उन लोगों के लिए विचार के लिए कुछ खाना है जो इस प्रश्न पर ठोकर खा सकते हैं।
जेएक्स-बीएस के साथ जेएक्स-आरएस का उपयोग करते समय मेरा एक ही सवाल था। मेरी आशा थी कि कक्षाओं में इंटरफेस पर जेएक्स-बी एनोटेशन का उपयोग न करें। यह मेरी अपेक्षा के अनुसार काम नहीं करता है, कारण unmarshaller के कारण है। मेरे मुद्दों को हल करने के लिए, मैं कक्षाओं का उपयोग कर समाप्त हो गया। Here एक विवरण है कि मुझे और क्यों मिला।
इसी तरह का प्रश्न यहां: http://stackoverflow.com/questions/11427283/benifits-of-using-java-interfaces-in-jax-rs-web-services – Kirby