मैं खोज रहा हूं कि स्प्रिंग 3.2.x का उपयोग करके REST API संस्करणों को कैसे प्रबंधित किया जाए, लेकिन मुझे ऐसा कुछ भी नहीं मिला है जिसे बनाए रखना आसान हो। मैं पहले बताई गई समस्या के बारे में समझाता हूँ, और फिर एक समाधान ... लेकिन मुझे आश्चर्य है कि अगर मैं यहाँ पहिया का पुनः आविष्कार कर रहा हूँ।
मैं स्वीकार शीर्ष लेख के आधार पर संस्करण का प्रबंधन करना चाहता हूं, और उदाहरण के लिए यदि अनुरोध में शीर्षक है application/vnd.company.app-1.1+json , तो मैं चाहता हूं कि वसंत एमवीसी इस विधि को आगे बढ़ाए जो इस संस्करण को संभालती है। और चूंकि एक ही रिलीज में एपीआई में सभी तरीके नहीं बदलते हैं, इसलिए मैं अपने प्रत्येक कंट्रोलर के पास नहीं जाना चाहता हूं और हैंडलर के लिए कुछ भी बदलना चाहता हूं जो संस्करणों के बीच नहीं बदला है। मैं यह भी तर्क नहीं देना चाहता हूं कि नियंत्रक (स्वयं सेवा लोकेटर का उपयोग करके) में संस्करण का उपयोग करने के लिए कौन सा संस्करण पहले से ही पता चल रहा है कि किस पद्धति को कॉल करना है।
इसलिए संस्करण 1.0 के साथ एक एपीआई लिया, 1.8 से जहां एक हैंडलर को 1.0 संस्करण में पेश किया गया था और v1.7 में संशोधित किया गया था, मैं इसे निम्नलिखित तरीके से संभालना चाहूंगा। कल्पना करें कि कोड एक नियंत्रक के अंदर है, और यह कुछ कोड है जो हेडर से संस्करण को निकालने में सक्षम है। (वसंत में निम्नलिखित अमान्य है)
@RequestMapping(...)
@VersionRange(1.0,1.6)
@ResponseBody
public Object method1() {
// so something
return object;
}
@RequestMapping(...) //same Request mapping annotation
@VersionRange(1.7)
@ResponseBody
public Object method2() {
// so something
return object;
}यह वसंत में संभव नहीं है क्योंकि 2 विधियों में एक ही RequestMappingएनोटेशन है और वसंत लोड करने में विफल रहता है। विचार यह है कि VersionRangeएनोटेशन एक खुली या बंद संस्करण सीमा को परिभाषित कर सकता है। पहली विधि संस्करण 1.0 से 1.6 तक मान्य है, जबकि दूसरा संस्करण 1.7 के बाद (नवीनतम संस्करण 1.8 सहित)। मुझे पता है कि यदि कोई व्यक्ति 99.99 संस्करण को पारित करने का फैसला करता है, तो यह दृष्टिकोण टूट जाता है, लेकिन यह एक ऐसी चीज है जिसके साथ मैं रहना चाहता हूं।
अब, चूंकि वसंत के काम करने के गंभीर तरीके के बिना उपरोक्त संभव नहीं है, मैं जिस तरह से हैंडलर अनुरोधों के साथ मेल खाता था, विशेष रूप से अपने खुद के लिखने के साथ छेड़छाड़ करने के बारे में सोच रहा था। ProducesRequestCondition , और वहां संस्करण रेंज है। उदाहरण के लिए
कोड:
@RequestMapping(..., produces = "application/vnd.company.app-[1.0-1.6]+json)
@ResponseBody
public Object method1() {
// so something
return object;
}
@RequestMapping(..., produces = "application/vnd.company.app-[1.7-]+json)
@ResponseBody
public Object method2() {
// so something
return object;
}इस तरह, मैं एनोटेशन के उत्पादन भाग में परिभाषित बंद या खुली संस्करण श्रेणियां रख सकता हूं। मैं अब इस समाधान पर काम कर रहा हूँ, समस्या यह है कि मैं अभी भी कुछ कोर स्प्रिंग MVC वर्गों को बदलने के लिए किया था (साथ RequestMappingInfoHandlerMapping, RequestMappingHandlerMappingऔर RequestMappingInfo,) है, जो मुझे पसंद नहीं है, क्योंकि यह अतिरिक्त काम का मतलब है जब भी मैं के एक नए संस्करण में नवीनीकृत करने का फैसला वसंत।
मैं किसी भी विचार की सराहना करता हूं ... और विशेष रूप से, किसी भी सुझाव को सरल बनाने के लिए, आसान बनाए रखने के लिए।
संपादित करें
एक इनाम जोड़ना। बाउंटी पाने के लिए, ऊपर दिए गए प्रश्न का उत्तर बिना नियंत्रक के यह तर्क देने के लिए दें। स्प्रिंग के पास पहले से ही बहुत सारे तर्क हैं कि कौन सी कंट्रोलर विधि का चयन करें, और मैं उस पर गुल्लक करना चाहता हूं।
संपादित करें २
मैंने github में मूल POC (कुछ सुधारों के साथ) साझा किया है: https://github.com/augusto/restVersioning
produces={"application/json-1.0", "application/json-1.1"}इत्यादि
