एपीआई संस्करण के लिए सर्वोत्तम अभ्यास? [बन्द है]

Question

क्या वेब सेवा REST API वर्जनिंग के लिए कोई ज्ञात थ्रू या सर्वोत्तम प्रथाएं हैं?

मैंने देखा है कि AWS समापन बिंदु के URL द्वारा संस्करणकरण करता है । क्या यह एकमात्र तरीका है या समान लक्ष्य को पूरा करने के अन्य तरीके हैं? यदि कई तरीके हैं, तो प्रत्येक तरीके की खूबियां क्या हैं?

Answer 1

यह एक अच्छा और पेचीदा प्रश्न है। URI डिजाइन का विषय एक ही समय में REST API का सबसे प्रमुख हिस्सा है और इसलिए, उस API के उपयोगकर्ताओं के लिए एक संभावित दीर्घकालिक प्रतिबद्धता है ।

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

दूसरी ओर, जीवन का एक और तथ्य यह है कि एपीआई के माध्यम से उपभोग किए जाने वाले सभी संसाधनों और उनके पहलुओं को दूर करना कठिन है। सौभाग्य से, पूरे एपीआई को डिज़ाइन करना आवश्यक नहीं है जो कि एपोकैलिप्स तक उपयोग किया जाएगा । यह सभी संसाधन अंत-बिंदुओं और हर संसाधन और संसाधन उदाहरण की एड्रेसिंग स्कीम को सही ढंग से परिभाषित करने के लिए पर्याप्त है।

समय के साथ आपको प्रत्येक विशेष संसाधन में नए संसाधनों और नई विशेषताओं को जोड़ने की आवश्यकता हो सकती है, लेकिन एक विशेष संसाधन तक पहुंचने के लिए एपीआई उपयोगकर्ता जिस विधि का पालन करते हैं, उसे संसाधन पते की योजना के सार्वजनिक होने और इसलिए अंतिम रूप से परिवर्तित नहीं होना चाहिए।

यह विधि HTTP क्रिया शब्दार्थ पर लागू होती है (जैसे PUT को हमेशा अद्यतन / प्रतिस्थापित करना चाहिए) और HTTP स्थिति कोड जो पहले के एपीआई संस्करणों में समर्थित हैं (उन्हें काम करना जारी रखना चाहिए ताकि एपीआई क्लाइंट जो मानव हस्तक्षेप के बिना काम कर चुके हैं, उन्हें काम जारी रखने में सक्षम होना चाहिए। उसके जैसा)।

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

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

एपीआई संस्करणों के रखरखाव के बारे में कुछ विचार जो उन पर समाप्ति की तारीख है। आमतौर पर वेब सेवाओं (जावा, .NET, PHP, पर्ल, रेल्स, आदि) को लागू करने के लिए उपयोग किए जाने वाले सभी प्रोग्रामिंग प्लेटफॉर्म / भाषाएं आधार URI के लिए वेब सेवा एंड-पॉइंट (एस) के आसान बंधन की अनुमति देती हैं। इस तरह विभिन्न एपीआई संस्करणों में अलग-अलग फ़ाइलों / वर्गों / विधियों का संग्रह इकट्ठा करना और रखना आसान है ।

एपीआई उपयोगकर्ताओं पीओवी से, एक विशेष एपीआई संस्करण के साथ काम करना और बांधना आसान है, जब यह स्पष्ट है लेकिन केवल सीमित समय के लिए, यानी विकास के दौरान।

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

हालांकि, URI में स्पष्ट रूप से दिखाई देने वाले API संस्करणों में एक चेतावनी है: एक व्यक्ति इस दृष्टिकोण पर भी आपत्ति जता सकता है क्योंकि API इतिहास URI डिजाइन में दृश्यमान / अपारदर्शी हो जाता है और इसलिए समय के साथ परिवर्तन के लिए प्रवण होता है जो REST के दिशानिर्देशों के विरुद्ध जाता है। मैं सहमत हूँ!

इस उचित आपत्ति के चारों ओर जाने का तरीका, संस्करण रहित एपीआई आधार URI के तहत नवीनतम एपीआई संस्करण को लागू करना है। इस मामले में, एपीआई क्लाइंट डेवलपर्स या तो चुन सकते हैं:

• नवीनतम के खिलाफ विकसित करना (अपने आप को एप्लिकेशन को बनाए रखने के लिए इसे अंतिम एपीआई परिवर्तनों से बचाने के लिए जो उनके बुरी तरह से डिज़ाइन किए गए एपीआई क्लाइंट को तोड़ सकते हैं )।

• एपीआई के एक विशिष्ट संस्करण के लिए बाध्य करें (जो स्पष्ट हो जाता है) लेकिन केवल एक सीमित समय के लिए

उदाहरण के लिए, अगर एपीआई v3.0 नवीनतम एपीआई संस्करण है, तो निम्नलिखित दो उपनाम होने चाहिए (यानी सभी अनुरोधों के लिए पहचान के अनुसार व्यवहार करें):

http: // shonzilla / api / customers / 1234 
http: // shonzilla / api /v3.0 / ग्राहक / 1234
http: // shonzilla / api / v3 / ग्राहक / 1234

इसके अलावा, एपीआई क्लाइंट जो अभी भी पुराने एपीआई को इंगित करने का प्रयास करते हैं, उन्हें नवीनतम पिछले एपीआई संस्करण का उपयोग करने के लिए सूचित किया जाना चाहिए, अगर वे जिस एपीआई संस्करण का उपयोग कर रहे हैं वह अप्रचलित है या अब समर्थित नहीं है । इसलिए किसी भी अप्रचलित URI को इस तरह से एक्सेस करना:

http: // shonzilla / api /v2.2 / ग्राहक / 1234
http: // shonzilla / api /v2.0 / ग्राहक / 1234
http: // shonzilla / api / v2 / customers / 1234
http: // shonzilla / api /v1.1 / ग्राहक / 1234
http: // shonzilla / api / v1 / ग्राहकों / 1234

30x HTTP स्थिति कोडों में से किसी को भी वापस करना चाहिए जो पुनर्निर्देशन को इंगित करता है जो LocationHTTP हेडर के साथ संयोजन के रूप में उपयोग किया जाता है जो कि संसाधन URI के उपयुक्त संस्करण पर पुनर्निर्देशित करता है जो कि यह बने रहते हैं:

http: // shonzilla / API / ग्राहकों / 1234

कम से कम दो पुनर्निर्देशन HTTP स्थिति कोड हैं जो API संस्करण परिदृश्यों के लिए उपयुक्त हैं:

• 301 स्थायी रूप से यह दर्शाता है कि अनुरोधित URI वाला संसाधन स्थायी रूप से दूसरे URI में ले जाया जाता है (जिसमें एक संसाधन उदाहरण पारलिंक होना चाहिए जिसमें API संस्करण जानकारी नहीं है)। इस स्थिति कोड का उपयोग अप्रचलित / असमर्थित एपीआई संस्करण को दर्शाने के लिए किया जा सकता है, जो एपीआई क्लाइंट को सूचित करता है कि एक संस्करणित संसाधन यूआरआई को रिसोर्स पर्मलिंक से बदल दिया गया है ।

• 302 यह दर्शाता है कि अनुरोधित संसाधन अस्थायी रूप से किसी अन्य स्थान पर स्थित है, जबकि अनुरोधित URI अभी भी समर्थित हो सकता है। यह स्थिति कोड तब उपयोगी हो सकता है जब संस्करण-आधारित URI अस्थायी रूप से अनुपलब्ध हो और यह अनुरोध पुनर्निर्देशन पते (जैसे APRI संस्करण के साथ URI की ओर इशारा करते हुए) का उपयोग करके दोहराया जाना चाहिए और हम ग्राहकों को इसका उपयोग करते रहने के लिए कहना चाहते हैं (यानी पर्मालिंक्स)।

• अन्य परिदृश्य HTTP 1.1 विनिर्देश के पुनर्निर्देशन 3xx अध्याय में पाए जा सकते हैं

Comments

अंतर्निहित कार्यान्वयन में परिवर्तन होने पर URL में संस्करण संख्या का उपयोग करना एक बुरा अभ्यास नहीं माना जाना चाहिए। "जब एक सेवा का इंटरफ़ेस एक गैर-पीछे-संगत-संगत तरीके से बदलता है, तो वास्तव में एक पूरी तरह से नई सेवा बनाई गई है ... ग्राहक के दृष्टिकोण से, एक सेवा इंटरफ़ेस और कुछ गैर-कार्यात्मक गुणों से अधिक नहीं है .. एक गैर-बैकवर्ड-संगत तरीके से सेवा में परिवर्तन के लिए इंटरफ़ेस को .if, यह अब मूल सेवा के एक उदाहरण का प्रतिनिधित्व नहीं करता है, बल्कि पूरी तरह से एक नई सेवा है। " ibm.com/developerworks/webservices/library/ws-version

— benvolioT

क्या आपके पास वर्जन नंबर के साथ हेडर जोड़ने के बारे में कोई विचार है ताकि इसे क्लाइंट या डेवलपर्स द्वारा जांचा जा सके?

— वेबक्लिम्बर

क्लाइंट को उम्मीद है कि संस्करण की ओर संकेत करने के लिए एक्सेप्ट हेडर का उपयोग भी देखें: blog.steveklabnik.com/2011/07/03/…

— वेस्टन

पिछले भाग के लिए: मैं कहूंगा कि एक एपीआई जो अप्रचलित है और अब समर्थित नहीं है उसे वापस लौटना चाहिए 410 Gone, क्योंकि एक रीडायरेक्ट इंगित कर सकता है कि नया स्थान संगत नहीं है। यदि एपीआई केवल अप्रचलित है, लेकिन अभी भी मौजूद है, Warningतो प्रतिक्रिया पर एक HTTP हैडर एक विकल्प हो सकता है।

— माइकल स्टम

आप उन ग्राहकों के साथ कैसे व्यवहार करते हैं जो पहले से ही shonzilla / api / customers / 1234 जैसे स्थिर URL का उपयोग कर रहे हैं और आप एक नए संस्करण में अपग्रेड करना चाहते हैं? आप उन्हें URL में V2 (पुराना वाला) जोड़ने के लिए कैसे बाध्य कर सकते हैं?

— देजेल

Answer 2

URL में संस्करण नहीं होने चाहिए। संस्करण का आपके द्वारा अनुरोधित संसाधन के "विचार" से कोई लेना-देना नहीं है। आपको उस URL के बारे में सोचने की कोशिश करनी चाहिए जो उस अवधारणा के लिए एक मार्ग है जो आप चाहते हैं - न कि कैसे आप आइटम वापस चाहते हैं। संस्करण वस्तु के प्रतिनिधित्व को निर्धारित करता है, वस्तु की अवधारणा को नहीं। जैसा कि अन्य पोस्टरों ने कहा है, आपको अनुरोध शीर्षलेख में प्रारूप (संस्करण सहित) निर्दिष्ट करना चाहिए।

यदि आप उन URL के पूर्ण HTTP अनुरोध को देखते हैं जिनके संस्करण हैं, तो यह इस तरह दिखता है:

(BAD WAY TO DO IT):

http://company.com/api/v3.0/customer/123
====>
GET v3.0/customer/123 HTTP/1.1
Accept: application/xml

<====
HTTP/1.1 200 OK
Content-Type: application/xml
<customer version="3.0">
  <name>Neil Armstrong</name>
</customer>

हेडर में वह पंक्ति होती है जिसमें वह प्रतिनिधित्व होता है जिसे आप पूछ रहे हैं ("स्वीकार करें: एप्लिकेशन / xml")। यह वह जगह है जहां संस्करण जाना चाहिए। हर कोई इस तथ्य पर प्रकाश डालना चाहता है कि आप एक ही चीज़ को अलग-अलग स्वरूपों में चाहते हैं और ग्राहक को यह पूछने में सक्षम होना चाहिए कि वह क्या चाहता है। उपरोक्त उदाहरण में, ग्राहक संसाधन के किसी भी XML प्रतिनिधित्व के लिए पूछ रहा है - वास्तव में जो वह चाहता है उसका सही प्रतिनिधित्व नहीं है। सर्वर, सिद्धांत रूप में, अनुरोध के लिए पूरी तरह से असंबंधित कुछ वापस कर सकता है जब तक यह एक्सएमएल था और इसे गलत होने का एहसास करने के लिए पार्स करना होगा।

एक बेहतर तरीका है:

(GOOD WAY TO DO IT)

http://company.com/api/customer/123
===>
GET /customer/123 HTTP/1.1
Accept: application/vnd.company.myapp.customer-v3+xml

<===
HTTP/1.1 200 OK
Content-Type: application/vnd.company.myapp-v3+xml
<customer>
  <name>Neil Armstrong</name>
</customer>

इसके अलावा, ग्राहकों को लगता है कि XML बहुत क्रियात्मक है और अब वे इसके बजाय JSON चाहते हैं। अन्य उदाहरणों में आपके पास एक ही ग्राहक के लिए एक नया URL होगा, इसलिए आप इसके साथ समाप्त होंगे:

(BAD)
http://company.com/api/JSONv3.0/customers/123
  or
http://company.com/api/v3.0/customers/123?format="JSON"

(या ऐसा ही कुछ)। जब वास्तव में, हर HTTP अनुरोध में वह प्रारूप होता है जिसे आप खोज रहे हैं:

(GOOD WAY TO DO IT)
===>
GET /customer/123 HTTP/1.1
Accept: application/vnd.company.myapp.customer-v3+json

<===
HTTP/1.1 200 OK
Content-Type: application/vnd.company.myapp-v3+json

{"customer":
  {"name":"Neil Armstrong"}
}

इस पद्धति का उपयोग करके, आपके पास डिज़ाइन में बहुत अधिक स्वतंत्रता है और वास्तव में REST के मूल विचार का पालन कर रहे हैं। आप क्लाइंट को बाधित किए बिना संस्करण बदल सकते हैं, या एपीआई बदले जाने पर ग्राहकों को अचानक बदल सकते हैं। यदि आप एक प्रतिनिधित्व का समर्थन बंद करना चुनते हैं, तो आप HTTP स्थिति कोड या कस्टम कोड के साथ अनुरोधों का जवाब दे सकते हैं। क्लाइंट सही प्रारूप में प्रतिक्रिया को सत्यापित कर सकता है, और XML को मान्य कर सकता है।

कई अन्य फायदे हैं और मैं उनमें से कुछ की चर्चा यहाँ अपने ब्लॉग पर करता हूँ: http://thereisnorightway.blogspot.com/2011/02/versioning-and-types-in-resthttp-api.html

एक अंतिम उदाहरण यह दिखाने के लिए कि URL में संस्करण कैसे डालना बुरा है। कहते हैं कि आप वस्तु के अंदर कुछ जानकारी चाहते हैं, और आपने अपनी विभिन्न वस्तुओं को संस्करणित किया है (ग्राहक v3.0 हैं, ऑर्डर v2.0 हैं, और शिप्टो ऑब्जेक्ट v4.2 है)। यहां वह गंदा URL है जो आपको क्लाइंट में देना चाहिए:

(Another reason why version in the URL sucks)
http://company.com/api/v3.0/customer/123/v2.0/orders/4321/

Comments

एक्सेप्ट हेडर में स्वतंत्र डेटा कॉन्ट्रैक्ट वर्जन और सर्विस कॉन्ट्रैक्ट वर्जन को हैंडल करना उतना ही गड़बड़ लगता है जितना कि यूआरएल में गड़बड़ होना। क्या कोई अन्य विकल्प भी हैं ? अगर मेरे पास कई एंडपॉइंट्स (साबुन, बाकी) हैं, तो क्या इसे भी स्वीकार किया जाना चाहिए और सर्वर एंड पर राउटिंग सर्विस को सही एंडपॉइंट की दिशा तय करने दें या क्या यह एंडपॉइंट यूआरएल में कोडेड होना स्वीकार्य है?

— विचार

मैं इससे सहमत नहीं हो सकता, कम से कम आपके अंतिम कारण की ओर। ऐसा लगता है कि यूआरआई के विभिन्न हिस्सों के अलग-अलग संस्करण हैं। लेकिन यह एक एपीआई संस्करण की बात नहीं है। बिंदु ENTIRE संसाधन के लिए एक संस्करण है। यदि आप संस्करण बदलते हैं, तो यह एक अलग एपीआई संसाधन है। यही कारण है कि company.com/api/v3.0/customer/123/v2.0/orders/4321 को देखने का कोई मतलब नहीं है , बल्कि company.com/api/v3.0/customer/123/orders/4321 को देखना है। आप संसाधन के किसी भी भाग को संस्करणबद्ध नहीं कर रहे हैं, आप संसाधन को संपूर्ण रूप में संस्करणबद्ध कर रहे हैं।

— fool4jesus

शीर्ष लेख में वर्जन संख्या का उपयोग करना बेहतर लगता है। लेकिन URL के उपयोग से इसका बहुत अधिक व्यावहारिक: कम त्रुटि वाला, सबसे अच्छा डीबग किया गया, डेवलपर्स द्वारा आसानी से देखा गया, बाकी परीक्षण ग्राहकों में आसानी से परिवर्तनीय।

— डैनियल सेरेकेडो

मुझे लगता है कि BAD / GOOD इस सवाल को सरल बनाता है। एपीआई "एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस" के लिए खड़ा है और संस्करण इंटरफ़ेस बहुत अच्छा विचार है। एपीआई वास्तव में केवल सेवारत संसाधनों के बारे में नहीं हैं। अलग करने की आवश्यकता क्या है कि कुछ लोग इंटरफेस के बारे में बात कर रहे हैं और अन्य लोग संसाधनों के बारे में बात कर रहे हैं। यदि आप नेटवर्क टैब में गूगल मैप्स एपी को बारीकी से देखते हैं, तो आप देखेंगे कि वे यूआरएल में एपीआई संस्करण संख्या को शामिल करते हैं। उदाहरण के लिए: प्रमाणीकरण के दौरान maps.google.com/maps/api/jsv2। Jsv2 एपी नंबर है।

— टॉम ग्रुनर

@ गिल्ली: वास्तव में, आपको अब इसका उपयोग नहीं करना चाहिए -xक्योंकि यह RFC6648 द्वारा दर्शाया गया है ।

— जोनाथन डब्ल्यू 10

Answer 3

हमने URL में संस्करण डालना व्यावहारिक और उपयोगी पाया। यह बताना आसान है कि आप एक नज़र में क्या उपयोग कर रहे हैं। स्वीकार किए गए उत्तर का सुझाव देते हुए, हम आसानी से उपयोग, छोटे / क्लीनर URL, आदि के लिए उपनाम / फू / टू / / (नवीनतम संस्करण) करते हैं।

हमेशा पीछे की संगतता को बनाए रखना अक्सर लागत-निषेधात्मक और / या बहुत कठिन होता है। हम यहां सुझाए गए, डॉक्स, और अन्य तंत्रों जैसे पुनर्निर्धारण की उन्नत सूचना देना पसंद करते हैं।

Comments

स्वीकृत उत्तर सही और सबसे शुद्ध हो सकता है। हालांकि, एपीआई के उपयोगकर्ता के लिए दिन और दिन के लिए यह निश्चित रूप से उपयोग और सेट अप करने के लिए सबसे आसान है। सबसे व्यावहारिक दृष्टिकोण। जैसा कि अन्य Google और अमेज़ॅन ने संकेत दिया है, इस दृष्टिकोण का भी उपयोग करते हैं।

— मुहम्मद रेहान सईद

Answer 4

मैं मानता हूं कि संसाधन प्रतिनिधित्व को बेहतर बनाना REST दृष्टिकोण का अनुसरण करता है ... लेकिन, कस्टम MIME प्रकारों (या MIME प्रकार जो एक संस्करण पैरामीटर को जोड़ते हैं) के साथ एक बड़ी समस्या HTML में स्वीकार और सामग्री-प्रकार हेडर को लिखने के लिए खराब समर्थन है। जावास्क्रिप्ट।

उदाहरण के लिए, संसाधन बनाने के लिए HTML5 रूपों में निम्नलिखित हेडर के साथ POST को IMO करना संभव नहीं है:

Accept: application/vnd.company.myapp-v3+json
Content-Type: application/vnd.company.myapp-v3+json 

ऐसा इसलिए है क्योंकि एचटीएमएल 5 enctypeविशेषता एक गणना है, इसलिए सामान्य के अलावा कुछ भी application/x-www-formurlencoded, multipart/form-dataऔर text/plainअमान्य हैं।

... और न ही मुझे यकीन है कि यह HTML4 में सभी ब्राउज़रों के लिए समर्थित है (जिसमें एक अधिक लैक्स एनकैप विशेषता है, लेकिन यह ब्राउज़र कार्यान्वयन मुद्दा होगा कि क्या MIME प्रकार को अग्रेषित किया गया था)

इस वजह से मुझे अब URI के माध्यम से सबसे उपयुक्त तरीका लगता है, लेकिन मैं स्वीकार करता हूं कि यह 'सही' तरीका नहीं है।

Comments

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

— काइल हेस

मुझे यकीन नहीं है कि मैं सहमत हूं कि यूआरआई सबसे उपयुक्त है, लेकिन यह तथ्य कि सामग्री-प्रकार रूपों के साथ काम नहीं करता है वास्तव में बहुत महत्वपूर्ण है।

— wprl

@ काइल, मैंने कहीं एक ब्लॉग देखा, जिसमें कहा गया है कि यदि आप अनुरोध शीर्ष लेख में कोई संस्करण निर्दिष्ट नहीं करते हैं, तो पहले एपीआई संस्करण के साथ वापस आना सबसे अच्छा है, जो कि सबसे अच्छा अनुकूल के लिए नवीनतम नहीं है।

— एंडी

यह वास्तव में मेरे लिए बहुत मायने रखता है जो अब मैं सोचता हूं।

— काइल हेस

@KyleHayes iframes, वीडियो / एम्बेड और अन्य "src / href" टाइप टैग को न भूलें।

— २१

Answer 5

अपने संस्करण को URI में रखें। एक एपीआई का एक संस्करण हमेशा दूसरे से प्रकारों का समर्थन नहीं करेगा, इसलिए यह तर्क कि संसाधन केवल एक संस्करण से दूसरे में माइग्रेट किए गए हैं, केवल सादे गलत हैं। यह XML से JSON पर स्विच करने के प्रारूप के समान नहीं है। प्रकार मौजूद नहीं हो सकते हैं, या वे शब्दार्थ बदल सकते हैं।

संस्करण संसाधन पते का हिस्सा हैं। आप एक API से दूसरे में रूट कर रहे हैं। हेडर में एड्रेसिंग को छुपाना RESTful नहीं है।

Answer 6

ऐसे कुछ स्थान हैं जहाँ आप REST API में संस्करणकरण कर सकते हैं:

1. जैसा कि कहा गया है, यूआरआई में। यह ट्रैडीटेबल और एस्थेटिक रूप से मनभावन भी हो सकता है यदि रीडायरेक्ट और समान का अच्छी तरह से उपयोग किया जाए।

2. स्वीकारें: शीर्षलेख में, इसलिए संस्करण फाइलटाइप में है। जैसे 'एमपी' बनाम 'mp4'। यह भी काम करेगा, हालांकि IMO की तुलना में यह थोड़ा कम काम करता है ...

3. संसाधन में ही। कई फ़ाइल स्वरूपों में उनके संस्करण संख्याएं होती हैं, जो आमतौर पर हेडर में होती हैं; यह नए सॉफ्टवेयर को 'सिर्फ काम' करने की अनुमति देता है, जबकि फाइलटेप के सभी मौजूदा संस्करणों को समझकर, जबकि पुराना सॉफ्टवेयर एक असमर्थित (नया) संस्करण निर्दिष्ट कर सकता है। REST API के संदर्भ में, इसका अर्थ है कि आपके URI को कभी भी बदलना नहीं है, बस आपके द्वारा दिए गए डेटा के विशेष संस्करण के प्रति आपकी प्रतिक्रिया।

मैं तीनों दृष्टिकोणों का उपयोग करने के लिए कारण देख सकता हूं:

1. यदि आप नए APIs को 'क्लीन स्वीप' करना पसंद करते हैं, या जहां आप इस तरह का दृष्टिकोण चाहते हैं, तो बड़े संस्करण में बदलाव के लिए।
2. यदि आप चाहते हैं कि ग्राहक को यह पता चले कि इससे पहले कि वह काम करने जा रहा है या नहीं तो क्या होगा।
3. अगर यह ठीक है अगर ग्राहक को अपना PUT / POST करना है तो यह पता करें कि क्या वह काम करने जा रहा है।

Answer 7

अपने REST API को बनाना किसी अन्य API के संस्करण के अनुरूप है। जगह में मामूली बदलाव किए जा सकते हैं, बड़े बदलावों के लिए पूरे नए एपीआई की आवश्यकता हो सकती है। आपके लिए सबसे आसान है कि आप हर बार स्क्रैच से शुरुआत करें, जब URL में वर्जन डालना सबसे ज्यादा मायने रखता है। यदि आप उस ग्राहक के लिए जीवन को आसान बनाना चाहते हैं जिसे आप पश्चगामी अनुकूलता बनाए रखने का प्रयास करते हैं, जिसे आप डिप्रेसेशन (स्थायी पुनर्निर्देशन), कई संस्करणों में संसाधन आदि के साथ कर सकते हैं। यह अधिक काल्पनिक है और इसके लिए अधिक प्रयास की आवश्यकता होती है। लेकिन यह भी है कि "कूल यूआरआई में बदलाव नहीं होता है"

अंत में यह किसी भी अन्य एपीआई डिजाइन की तरह है। ग्राहक की सुविधा के खिलाफ वजन का प्रयास। अपने एपीआई के लिए अर्थ वर्जनिंग को अपनाने पर विचार करें, जो आपके ग्राहकों के लिए यह स्पष्ट करता है कि आपका नया संस्करण कितना पीछे है।