वेब सेवा संस्करण और सर्वर साइड हैंडलिंग

Question

मैं वेब सेवा संस्करण के लिए एक रणनीति तैयार करने और एससीएम बिंदु दृश्य से संस्करणों को संभालने का प्रयास कर रहा हूं।

हम नीचे-अप (जेएक्स-डब्ल्यूएस) सेवाएं कर रहे हैं, और इसलिए स्कीमा पर कम नियंत्रण है और सर्वोत्तम प्रथाओं के कुछ स्कीमा संस्करण का पालन नहीं कर सकते हैं। मेरे वर्तमान विचार कर रहे हैं:

1) बड़े परिवर्तनों (गैर पीछे की ओर संगत):

• नई सेवा URL (URL संस्करण) के माध्यम से API ग्राहक को प्रेषित किया। उदा .:

http://com.example/v1/MyService

http://com.example/v2/MyService

यह मेरी राय कम दोनों क्लाइंट और डेवलपर्स के लिए परेशानी में कारण बनता है। क्लाइंट सभी सेवा कॉल को अपडेट करने के बजाय केवल सेवा यूआरएल (आमतौर पर एक ही स्थान पर) अपडेट करता है (जैसे सेवा नाम संस्करण - MyServiceV1, MyServiceV2, ...) का उपयोग करते समय।

• सर्वर की तरफ, यह एसवीएन में सेवा टैग करके प्रतिबिंबित होता है: MyService- [major]। [मामूली] E.g. MyService-1,0

2) माइनर परिवर्तन (पीछे की ओर-संगत):

• यह जहां मैं और अधिक संदेह है। कुछ सर्वोत्तम प्रथाओं में, स्कीमा नेमस्पेस को संशोधित करना शामिल है जो बदले में संगत ग्राहकों के लिए अपग्रेड करना शामिल है।

• सर्वर साइड में स्पष्ट है के रूप में मैं रणनीति ऊपर उपयोग कर रहा हूँ ([SERVICE_NAME] - [प्रमुख] [नाबालिग]।)

के लिए ऊपर की रणनीति पर राय और सुझावों की सराहना करते हैं मामूली संस्करण।

Answer 1

प्रमुख संस्करण के लिए मुझे लगता है कि आप सही रास्ते में हैं, मैं "v" हालांकि, केवल संख्या का उपयोग नहीं करता।

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

यदि आप दो छोटे बदलावों को तोड़ते हैं, तो आप विधि संस्करण के लिए, उसी संस्करण के बारे में बता सकते हैं जैसा आपने प्रमुख संस्करणों के बारे में कहा था।