वेनिला सर्लेट्स

Question

के बजाय जावा में रीस्टफुल सेवाओं के लिए ढांचे का उपयोग क्यों करें मुझे पता है कि पुस्तकालयों के बारे में कुछ प्रश्न हैं जिनका उपयोग आप जावा में रीस्टफुल सेवाओं के लिए कर सकते हैं, लेकिन वेनिला कार्यान्वयन के खिलाफ उनका उपयोग करने में क्या मूल्य है। मेरा मतलब है, अगर मैं the url structure described by Wim

• www.example.com/images बनाने के लिए
• www.example.com/images/id/num
• www.example.com/images/tag/ देख रहा था संख्या
• www.example.com/images/tag/num/num/num

यह (लागू करने और सीखने के लिए) यूआरएल ढांचा/छवियों मैप करने के लिए (भविष्य डेवलपर्स के लिए) आसान और तेज नहीं होगा एक सर्वलेट के लिए और एक पंक्ति या दो है जो पैरामीटर के लिए यूआरएल पार्स करता है o इन पुस्तकालयों में से एक को आपके लिए करने के लिए सीखना, कार्यान्वित करना और कॉन्फ़िगर करना।

• Apache CXF
• Jersey (लोकप्रिय)
• Restlet (JAX-रुपये के अग्रणी)
• RESTEasy

अनिवार्य रूप से क्या मैं पूछ रहा हूँ है ... क्या उपयोग करने में मूल्य है एक शानदार जावा ढांचा? क्या यह एक साधारण समस्या के लिए कार्यान्वयन में बहुत जटिलता नहीं जोड़ रहा है?

संपादित करें: यह जर्सी कोड बहुत अच्छी तरह से संभाला जाता है और हर किसी को यह पता होना चाहिए कि सर्लेट फॉर्म में इसे कैसे किया जाए यदि वे पुस्तकालयों को उनके लिए ऐसा करने के लिए देख रहे हों।

@Path("/helloworld") 
public class HelloWorldResource { 

    // The Java method will process HTTP GET requests 
    @GET 
    // The Java method will produce content identified by the MIME Media 
    // type "text/plain" 
    @Produces("text/plain") 
    public String helloWorld() { 
     // Return some cliched textual content 
     return "Hello World"; 
    } 
} 

तो सब कर जा रहे हैं एक "सेवा" है कि पाठ कि URL पैरामीटर के द्वारा संचालित है, तो सादा पाठ रिटर्न देता है, एक रूपरेखा के लिए आवश्यक है?

Answer 1

यह (लागू करने और सीखने के लिए) एक सर्वलेट को यूआरएल ढांचा /images नक्शा और एक पंक्ति या दो है कि शिक्षा के बजाय मापदंडों के लिए यूआरएल को पार्स करता है करने के लिए (भविष्य डेवलपर्स के लिए) आसान और तेज नहीं होगा, इन पुस्तकालयों में से एक को आपके लिए करने के लिए कार्यान्वित करना और कॉन्फ़िगर करना।
...

आसान? यह निश्चित रूप से लिखना आसान नहीं है - आपको अपने सभी पथ निष्कर्षण और सभी विधि हैंडलिंग और सभी सामग्री प्रकार वार्ता ( दिशाओं में) और सभी कुकी हैंडलिंग और ऑब्जेक्ट deserialization/serialization thunks और ... अच्छी तरह से, बहुत कम स्तर की चीजें जिन्हें सभी को परीक्षण और डिबगिंग की आवश्यकता होगी - या या तो बनाए रखने में आसान है, क्योंकि जेएक्स-आरएस इंटरफेस आपको अनुरोधों के बजाय संसाधनों (रीस्टफुल वेबपैप्स की प्राकृतिक विशेषता) के स्तर पर काम करने देता है; अधिक अनुभव के साथ, रखरखाव मॉडल और कार्यान्वयन के बीच का अंतर सबसे छोटा है जब रखरखाव सबसे आसान है। यह लागू करने के लिए भी तेज़ नहीं है (क्योंकि जेएक्स-आरएस के निम्न स्तर के कार्यान्वयन पहले से ही आपके लिए परीक्षण किए गए हैं और डीबग किए गए हैं; आपके लिए कम करना) और सीखने की लागत बहुत अधिक नहीं है क्योंकि यह अधिकतर घोषणात्मक API है बहुत कम आश्चर्य के साथ।

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

(इससे पहले कि आप पूछें, आपके द्वारा वर्णित कुछ पुस्तकालयों में खुद को सर्वलेट के रूप में स्थापित किया जाएगा; इससे आपके कोड को सर्वलेट के व्यावसायिक तर्क का वर्णन करने की अनुमति मिलती है और घोषित किया जाता है कि वायर को मैपिंग को सार शब्दों में कैसे किया जाता है। यह सिर्फ काफी आसान)

Answer 2

जेएक्स-आरएस एक बहुत ही अच्छी तरह से डिज़ाइन किया गया एपीआई है जो विधियों के HTTP अनुरोधों को मैपिंग करता है, HTTP अनुरोध के विभिन्न हिस्सों से पैरामीटर निकालने, सामग्री बातचीत को संभालने, और कई अन्य निम्न स्तर के कार्यों को बहुत आसान बनाता है।

मुख्य रूप से अपाचे सीएक्सएफ के माध्यम से, जेएक्स-आरएस का उपयोग, लगभग दो साल से, मैं हमेशा इसे सादे सर्वलेट्स पर पसंद करता हूं।

Answer 3

फ्रेमवर्क का उपयोग आपको कार्य को और अधिक आसान बनाने के लिए किया जाता है। मैं सहमत हूं कि हम servlets को लागू करके वही काम कर सकते हैं और फिर यूआरएल पार्स कर सकते हैं और फिर मूल तर्क लागू कर सकते हैं।

Bu यदि आप जर्सी जैसे ढांचे का उपयोग कर रहे हैं तो आपको उन पार्सिंग पैटर्न और अन्य समान कार्यों के बारे में चिंता करने की ज़रूरत नहीं है। ServletContainer क्लास इसका ख्याल रखेगा (इसकी सेवा विधि में यूआरएल पार्सिंग) और वहां कई अन्य वर्ग भी हैं जो आपके काम को आसान बना देंगे।

और एक और चीज हम केवल एक ही परिदृश्य (मिलान पैटर्न) ले रहे हैं, लेकिन जब हमारी आवश्यकताएं बढ़ेगी तो हमारे स्वयं के सर्वलेट द्वारा लिखे गए एक ही कोड अधिक जटिल और जटिल हो जाएंगे।

Answer 4

मैं, इस मामले में जर्सी या एक पुस्तकालय का उपयोग कर के साथ जाना होगा यदि वह निम्न (कहते हैं पर्याप्त मूल्य) करता है:।

• URL के लिए config सब एक के भीतर आत्म निहित है फ़ाइल, स्रोत
• के साथ कोई छिपी हुई कॉन्फ़िगरेशन फ़ाइलें या अत्यधिक क्रिया नहीं है ose configs (उदा। web.xml)
• मानकों अच्छी तरह से दृढ़ता से लिखे गए चर मैप की जाती हैं (उदाहरण के लिए एनोटेशन के उपयोग)
• यह पैरामीटर के मान को पाने के लिए घुमावदार नहीं है (उदाहरण के लिए RESTlet)
• पुस्तकालय चलाने के लिए भूमि के ऊपर है कम
• यह अच्छी तरह से प्रलेखित
• यह अच्छी तरह से

अपनाया है ऐसी स्थिति में (मैं अन्य पुस्तकालयों में प्रतिबिंब समाधान के साथ बुरे अनुभव पड़ा है), मुझे लगता है कि एक पुस्तकालय विज्ञापन का उपयोग करते हुए इसका उपयोग करने के लिए आवश्यक प्रयास के लिए मेरी परियोजना के लिए डी मूल्य। जर्सी काफी आवश्यकताओं को पूरा करने के लिए प्रतीत होता है, हालांकि मैंने अभी तक अन्य ढांचे को पर्याप्त जांच नहीं दी है।