REST URI को संस्करण देने का सबसे अच्छा तरीका क्या है? वर्तमान में हमारे पास URI यानी # में एक संस्करण है।
http://example.com/users/v4/1234/
इस प्रतिनिधित्व के संस्करण 4 के लिए।
क्या संस्करण क्वेरीस्ट्रिंग में है? अर्थात।
http://example.com/users/1234?version=4
या सबसे अच्छा तरीका है एक और तरीका है?
जवाबों:
मैं कहूंगा कि इसे URI का हिस्सा बनाना (विकल्प 1) सबसे अच्छा है क्योंकि v4 v3 की तुलना में एक अलग संसाधन की पहचान करता है। आपके दूसरे विकल्प की तरह क्वेरी पैरामीटर का उपयोग संसाधन के बजाय अनुरोध से संबंधित अतिरिक्त (क्वेरी) जानकारी को पास करने के लिए किया जा सकता है ।
URL न करें, क्योंकि ...
यह मानते हुए कि आपका संसाधन एप्लिकेशन / vnd.yourcompany.user + xml के कुछ संस्करण लौटा रहा है, आपको बस एक नए एप्लिकेशन / vnd.yourcompany.userV2 + xml मीडिया प्रकार के लिए समर्थन बनाने की आवश्यकता है और सामग्री वार्ता के जादू के माध्यम से अपने v1 और। v2 क्लाइंट शांति से सह-अस्तित्व में हो सकते हैं।
एक रिस्टफुल इंटरफ़ेस में, आपके पास एक अनुबंध के लिए निकटतम चीज़ मीडिया-प्रकार की परिभाषा है जो क्लाइंट और सर्वर के बीच बदले जाते हैं।
सर्वर के साथ बातचीत करने के लिए क्लाइंट द्वारा उपयोग किए जाने वाले URL पहले से पुनर्प्राप्त अभ्यावेदन में एम्बेडेड सर्वर द्वारा प्रदान किए जाने चाहिए। एकमात्र URL जिसे क्लाइंट द्वारा जाना जाना चाहिए, वह इंटरफ़ेस का रूट URL है। यदि आप क्लाइंट पर उरल्स का निर्माण करते हैं, तो आप केवल एक रैस्टोरफुल इंटरफेस के साथ ऐसा करने के लिए नहीं हैं, तो केवल यूआरएल में संस्करण संख्याओं को जोड़ने का मूल्य है।
यदि आपको अपने मीडिया-प्रकारों में बदलाव करने की आवश्यकता है जो आपके मौजूदा ग्राहकों को तोड़ देगा तो एक नया बनाएं और अपने यूआरएल को अकेला छोड़ दें!
और उन पाठकों के लिए जो वर्तमान में कह रहे हैं कि इसका कोई मतलब नहीं है अगर मैं एप्लिकेशन-एक्सएमएल और एप्लिकेशन / जसन को मीडिया-प्रकार के रूप में उपयोग कर रहा हूं। हम उन लोगों को कैसे संस्करण देने वाले हैं? तुम नहीं। जब तक आप उन्हें कोड-डाउनलोड का उपयोग करके पार्स नहीं करते हैं, तब तक वे मीडिया-प्रकार बहुत अधिक बेकार होते हैं, जिस बिंदु पर वर्जनिंग एक मूट पॉइंट है।
आह, मैं अपनी पुरानी क्रोधी टोपी फिर से डाल रहा हूं।
ReST परिप्रेक्ष्य से, यह बिल्कुल भी मायने नहीं रखता है। सॉसेज नहीं है।
ग्राहक एक यूआरआई प्राप्त करता है जिसे वह पालन करना चाहता है, और इसे एक अपारदर्शी स्ट्रिंग के रूप में मानता है। इसमें जो कुछ भी आप चाहते हैं, डाल दें, क्लाइंट को इस पर एक संस्करण पहचानकर्ता के रूप में ऐसी कोई जानकारी नहीं है।
क्लाइंट को पता है कि यह मीडिया प्रकार को संसाधित कर सकता है, और मैं डारेल की सलाह का पालन करने की सलाह दूंगा। इसके अलावा, मुझे व्यक्तिगत रूप से लगता है कि 4 बार आराम करने के लिए उपयोग किए जाने वाले प्रारूप को बदलने की आवश्यकता है, बड़े पैमाने पर बड़े पैमाने पर चेतावनी के संकेत लाने चाहिए जो कि आप कुछ गंभीर रूप से गलत कर रहे हैं, और पूरी तरह से बदलाव के लिए अपने मीडिया प्रकार को डिज़ाइन करने की आवश्यकता को दरकिनार कर दें।
लेकिन किसी भी तरह से, ग्राहक केवल एक दस्तावेज़ को एक प्रारूप के साथ संसाधित कर सकता है जिसे वह समझ सकता है, और इसमें लिंक का पालन कर सकता है। यह लिंक रिश्तों (बदलाव) के बारे में पता होना चाहिए। तो क्या यूआरआई पूरी तरह अप्रासंगिक है।
मैं व्यक्तिगत रूप से http: // localhost / 3f3405d5-5984-4683-bf26-aca186d21c04 के लिए मतदान करूंगा
एक पूरी तरह से मान्य पहचानकर्ता जो किसी भी आगे के क्लाइंट डेवलपर या सिस्टम को छूने वाले व्यक्ति को सवाल करने से रोकेगा अगर किसी को शुरुआत में या यूआरआई के अंत में v4 डालना चाहिए (और मेरा सुझाव है कि, सर्वर के नजरिए से, आपके पास 4 नहीं होना चाहिए संस्करण, लेकिन 4 मीडिया प्रकार)।
आपको URL में संस्करण नहीं डालना चाहिए, आपको संस्करण को अनुरोध के स्वीकारकर्ता में रखना चाहिए - इस धागे पर मेरी पोस्ट देखें:
एपीआई संस्करण के लिए सर्वोत्तम अभ्यास?
यदि आप URL में चिपके हुए संस्करण शुरू करते हैं तो आप इस तरह मूर्खतापूर्ण URL के साथ समाप्त होते हैं: http://company.com/api/v3.0/customer/123/v2.0/orders/4321/
और अन्य समस्याओं का एक समूह है जो रेंगते हैं - मेरे ब्लॉग को देखें: http://thereisnorightway.blogspot.com/2011/02/versioning-and-types-in-resthttp-api.html
REST API संस्करण के बारे में ये (कम-विशिष्ट) SO प्रश्न मददगार हो सकते हैं:
एपीआई के संस्करण के लिए 4 अलग-अलग दृष्टिकोण हैं:
URI पथ में संस्करण जोड़ना:
http://example.com/api/v1/foo
http://example.com/api/v2/foo
जब आपके पास परिवर्तन होता है, तो आपको संस्करण को बढ़ाना होगा: v1, v2, v3 ...
आप इस तरह से एक नियंत्रक को लागू कर सकते हैं:
@RestController
public class FooVersioningController {
@GetMapping("v1/foo")
public FooV1 fooV1() {
return new FooV1("firstname lastname");
}
@GetMapping("v2/foo")
public FooV2 fooV2() {
return new FooV2(new Name("firstname", "lastname"));
}
अनुरोध पैरामीटर संस्करण:
http://example.com/api/v2/foo/param?version=1
http://example.com/api/v2/foo/param?version=2
संस्करण पैरामीटर वैकल्पिक हो सकता है या आवश्यक है यह इस बात पर निर्भर करता है कि आप एपीआई का उपयोग कैसे करना चाहते हैं।
कार्यान्वयन इसके समान हो सकता है:
@GetMapping(value = "/foo/param", params = "version=1")
public FooV1 paramV1() {
return new FooV1("firstname lastname");
}
@GetMapping(value = "/foo/param", params = "version=2")
public FooV2 paramV2() {
return new FooV2(new Name("firstname", "lastname"));
}
एक कस्टम हेडर पास करना:
http://localhost:8080/foo/produces
हेडर के साथ:
headers[Accept=application/vnd.company.app-v1+json]
या:
headers[Accept=application/vnd.company.app-v2+json]
इस योजना का सबसे बड़ा लाभ ज्यादातर शब्दार्थ है: आप वर्जन के साथ कुछ भी करने के लिए यूआरआई को अव्यवस्थित नहीं कर रहे हैं।
संभावित कार्यान्वयन:
@GetMapping(value = "/foo/produces", produces = "application/vnd.company.app-v1+json")
public FooV1 producesV1() {
return new FooV1("firstname lastname");
}
@GetMapping(value = "/foo/produces", produces = "application/vnd.company.app-v2+json")
public FooV2 producesV2() {
return new FooV2(new Name("firstname", "lastname"));
}
होस्टनाम बदलना या API गेटवे का उपयोग करना:
अनिवार्य रूप से, आप एपीआई को एक होस्टनाम से दूसरे में स्थानांतरित कर रहे हैं। आप शायद इस इमारत को उन्हीं संसाधनों के लिए एक नया एपीआई भी कह सकते हैं।
इसके अलावा, आप एपीआई गेटवे का उपयोग करके ऐसा कर सकते हैं।
यदि REST सेवाओं को उपयोग करने से पहले प्रमाणीकरण की आवश्यकता होती है, तो आप API कुंजी / टोकन को API संस्करण के साथ आसानी से संबद्ध कर सकते हैं और आंतरिक रूप से रूटिंग कर सकते हैं। एपीआई के एक नए संस्करण का उपयोग करने के लिए, एक नई एपीआई कुंजी की आवश्यकता हो सकती है, जो उस संस्करण से जुड़ी हुई है।
दुर्भाग्य से, यह समाधान केवल स्थित-आधारित API के लिए काम करता है। हालाँकि, यह संस्करणों को URI से बाहर रखता है।
मैं संस्करण वाले एपीआई बनाना चाहता था और मुझे यह लेख बहुत उपयोगी लगा:
http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http
"मैं चाहता हूं कि मेरा एपीआई संस्करण हो" पर एक छोटा सा खंड है। मुझे यह सरल और समझने में आसान लगा। क्रूक्स संस्करण जानकारी को पास करने के लिए हेडर में स्वीकार क्षेत्र का उपयोग करना है।
मैं संस्करण को URI के अंत में एक वैकल्पिक मूल्य के रूप में शामिल करता हूँ। यह एक प्रत्यय की तरह हो सकता है जैसे / V4 या एक क्वेरी पैरामीटर जैसा आपने वर्णित किया है। आप क्वेरी पैरामीटर को / V4 को भी रीडायरेक्ट कर सकते हैं ताकि आप दोनों विविधताओं का समर्थन कर सकें।
यदि आप संस्करण के लिए यूआरआई का उपयोग करते हैं, तो संस्करण संख्या एपीआई रूट के यूआरआई में होनी चाहिए, इसलिए प्रत्येक संसाधन पहचानकर्ता इसमें शामिल हो सकते हैं।
तकनीकी रूप से एक REST API URL परिवर्तनों (एकसमान इंटरफ़ेस बाधा का परिणाम) से नहीं टूटता है। यह तभी टूटता है जब संबंधित शब्दार्थ (उदाहरण के लिए एपीआई विशिष्ट आरडीएफ शब्द) एक गैर-पिछड़े संगत तरीके (दुर्लभ) में बदलता है। वर्तमान में बहुत सारे पीपीएल नेविगेशन (HATEOAS बाधा) के लिए लिंक का उपयोग नहीं करते हैं और अपने आरएएस प्रतिक्रियाओं (स्व-वर्णनात्मक संदेश बाधा) को एनोटेट करने के लिए वोकैब करते हैं, यही कारण है कि उनके क्लाइंट टूट जाते हैं।
कस्टम MIME प्रकार और MIME प्रकार का संस्करण मदद नहीं करता है, क्योंकि संबंधित मेटाडेटा और प्रतिनिधित्व की संरचना को एक छोटी स्ट्रिंग में डालने से काम नहीं होता है। ऑप्टिकल फाइबर केबल। मेटाडेटा और संरचना अक्सर बदल जाएगी, और इसलिए संस्करण संख्या भी ...
तो अपने प्रश्न का उत्तर देने का सबसे अच्छा तरीका है कि आप अपने अनुरोधों और प्रतिक्रियाओं को वोकैब ( हाइड्रा , लिंक्ड डेटा ) के साथ एनोटेट करें और वर्जनिंग को भूल जाएं या इसका उपयोग केवल गैर-पिछड़े संगत वोकैब परिवर्तन द्वारा करें (उदाहरण के लिए यदि आप एक वोकैब को दूसरे के साथ बदलना चाहते हैं)।
मैं इसे माइम प्रकार में करने के लिए वोट करता हूं लेकिन URL में नहीं। लेकिन इसका कारण अन्य लोगों की तरह नहीं है।
मुझे लगता है कि अद्वितीय संसाधन का पता लगाने के लिए URL अद्वितीय होना चाहिए (उन रीडायरेक्ट को छोड़कर)। इसलिए, यदि आप स्वीकार /v2.0यूआरएल में, यह क्यों नहीं है /ver2.0या /v2/या /v2.0.0? या भी -alphaऔर -beta? (तब यह पूरी तरह से सेमर की अवधारणा बन जाती है )
तो, माइम प्रकार का संस्करण URL की तुलना में अधिक स्वीकार्य है।