जब @RestController बनाम @RepositoryRestResource का उपयोग करें


87

मैं REST के साथ स्प्रिंग का उपयोग करने के विभिन्न उदाहरणों को देख रहा हूं । हमारा अंतिम लक्ष्य स्प्रिंग HATEOAS/HALसेटअप है

मैंने वसंत के भीतर REST प्रदान करने के लिए दो अलग-अलग तरीके देखे हैं

  1. के माध्यम से @RestControllerएक नियंत्रक के भीतर

  2. @RepositoryRestResourceएक रिपॉजिटरी के भीतर वाया

मैं जिस चीज को पाने के लिए संघर्ष कर रहा हूं, वह यह है कि आप एक-दूसरे का उपयोग क्यों करेंगे। जब लागू करने की कोशिश कर रहा है HALजो सबसे अच्छा है?

हमारा डेटाबेस बैकएंड Neo4j है

जवाबों:


61

ठीक है, इसलिए छोटी कहानी यह है कि आप इसका उपयोग करना चाहते हैं @RepositoryRestResourceक्योंकि यह स्प्रिंग जेपीए के साथ एक HATEOAS सेवा बनाता है ।

जैसा कि आप देख सकते हैं यहाँ यह व्याख्या जोड़ने और इसे अपने Pojo को जोड़ने आप एक पूरी तरह कार्यात्मक है HATEOAS भंडार विधि या बाकी सेवा के तरीकों को लागू करने के बिना सेवा

यदि आप जोड़ते हैं @RestControllerतो आपको प्रत्येक विधि को लागू करना होगा जिसे आप अपने दम पर उजागर करना चाहते हैं और यह भी इसे हेटोस प्रारूप में निर्यात नहीं करता है ।


7
डिफ़ॉल्ट रूप से, स्प्रिंग डेटा रीस्ट सभी शीर्ष-स्तरीय, सार्वजनिक इंटरफ़ेस रिपॉजिटरी का निर्यात करेगा। आपको केवल एक इंटरफ़ेस निर्यात करने या समापन बिंदु के विवरण को बदलने के लिए @RepositoryRestResource की आवश्यकता नहीं है।
ग्रेगटर्न

4
यदि आप स्प्रिंग डेटा रीस्ट के साथ रेस्टकंट्रोलर का उपयोग करते हैं, तो आप स्प्रिंग डेटा रीस्ट को प्रदान करने वाले सभी को अलग कर देंगे। एक कस्टम स्प्रिंग MVC कंट्रोलर को कोड करने के लिए जो स्प्रिंग डेटा REST के संदेश कन्वर्टर्स आदि का उपयोग करता है, BasePathAwareController में देखें।
ग्रेगटर्न

मुझे नहीं लगता कि स्वीकार किया गया उत्तर सही है @gregturn के पास बेहतर उत्तर है।
मार्क

39

एक तीसरा (और चौथा) विकल्प है जिसे आपने उल्लिखित नहीं किया है, जिसका उपयोग या तो @BasePathAwareController या @RepositoryRestController है, जो इस बात पर निर्भर करता है कि आप इकाई-विशिष्ट कार्य कर रहे हैं या नहीं।

@RepositoryRestResource का उपयोग सार्वजनिक रिपॉजिटरी इंटरफ़ेस पर विकल्प सेट करने के लिए किया जाता है - यह स्वतः ही रिपॉजिटरी के प्रकार के आधार पर उपयुक्तता बनाएगा जिसे विस्तारित किया जा रहा है (यानी CrudRepository / PagingAndSingingRepository / etc)।

@BasePathAwareController और @RepositoryRestController का उपयोग तब किया जाता है जब आप मैन्युअल रूप से समापन बिंदु बनाना चाहते हैं, लेकिन आपके द्वारा सेट किए गए स्प्रिंग डेटा रीस्ट कॉन्फ़िगरेशन का उपयोग करना चाहते हैं।

यदि आप @RestController का उपयोग करते हैं, तो आप अलग-अलग कॉन्फ़िगरेशन विकल्पों के साथ समापन बिंदुओं का एक समानांतर सेट बनाएंगे - यानी एक अलग संदेश कनवर्टर, विभिन्न त्रुटि हैंडलर, आदि - लेकिन वे खुशी से सहअस्तित्व करेंगे (और शायद भ्रम पैदा करेंगे)।

विशिष्ट दस्तावेज यहां देखे जा सकते हैं


6
मुझे लगता है कि यह अब सच नहीं है। यदि @RestControllerसमान पथ का उपयोग करता है @RepositoryRestResource, तो रिपॉजिटरी एंडपॉइंट नहीं बनाए जाएंगे।
ह्यूबर्ट ग्रॉस्स्कोविआक

19

खैर, उपरोक्त उत्तर उनके संदर्भ में सही हैं फिर भी मैं आपको व्यावहारिक उदाहरण दे रहा हूं।

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

स्प्रिंग ने यहां क्या किया, आपको इन अंत बिंदुओं को ऐसे इंटरफेस (रिपॉजिटरी) से उजागर करने की अनुमति देता है जो आमतौर पर खोज इकाई के लिए जीईटी कॉल होते हैं और पृष्ठभूमि में अंतिम समापन बिंदु बनाने के लिए आवश्यक फाइलें उत्पन्न करते हैं। इसलिए यदि आप @RepositoryRestResource का उपयोग कर रहे हैं तो सेवा / नियंत्रक परत बनाने की कोई आवश्यकता नहीं है।

दूसरी ओर @RestController एक नियंत्रक है जो विशेष रूप से json डेटा से संबंधित है और एक नियंत्रक के रूप में काम करता है। संक्षेप में @Controller + @ResponseBody = @RestController।

उम्मीद है की यह मदद करेगा।

इसके लिए मेरा काम करने का उदाहरण और ब्लॉग देखें:
http://sv-technical.blogspot.com/2015/11/spring-boot-and-repositoryrestresource.html
https://github.com/svermaji/Spring-boot-with -hibernate-नो-नियंत्रक


मैं अपने ब्लॉग पर जा रहे लोगों को देख सकता हूं, अगर यह समाधान काम करता है तो कृपया वोट करें।
17

10

@RepositoryRestController डिफ़ॉल्ट रिपोजिटरी से डिफॉल्ट जेनरेट किया गया स्प्रिंग डेटा रीस्ट कंट्रोलर।

स्प्रिंग डेटा रीस्ट की सेटिंग्स, संदेश कन्वर्टर्स, अपवाद से निपटने, और अधिक का लाभ उठाने के लिए, @RepositoryRestControllerमानक स्प्रिंग RVC @Controllerया के बजाय एनोटेशन का उपयोग करें@RestController

उदा। यह नियंत्रक spring.data.rest.basePathरूटिंग के लिए आधार पथ के रूप में स्प्रिंग बूट सेटिंग का उपयोग करता है।

देखें अधिभावी स्प्रिंग डाटा बाकी रिस्पांस हैंडलर

जोड़ने के बारे में पता होना चाहिए @ResponseBodyक्योंकि यह याद किया जाता है@RepositoryRestController

यदि आप रिपॉजिटरी (के रूप में चिह्नित @RepositoryRestResource(exported = false)) उजागर नहीं करते @BasePathAwareControllerहैं, तो इसके बजाय एनोटेशन का उपयोग करें

बैग के बारे में भी जानकारी रखें

ControllerLinkBuilderस्प्रिंग डेटा रीस्ट के आधार पथ को ध्यान में नहीं रखता है और @RequestMappingइसे कक्षा / प्रकार के स्तर पर उपयोग नहीं किया जाना चाहिए

तथा

बेस पथ एचएएल में दिखाई नहीं देता है

लिंक को ठीक करने के लिए समाधान: https://stackoverflow.com/a/51736503/548473

अद्यतन: अंत में मैं @RepositoryRestControllerबहुत सारे वर्कअराउंड के कारण उपयोग नहीं करना पसंद करता हूं ।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.