पाठ 13 / 25
वर्ज़निंग रणनीतियाँ
URI, header और media-type versioning strategies की तुलना करें और स्पष्ट migration window के साथ deprecation plan करें।
URI वर्ज़निंग
व्यवहार में सबसे आम तरीका — दिखने वाला, कैश-योग्य, और रूट करना आसान, कीमत यह कि URI को वर्ज़न में दोहराना पड़ता है।
GET /v1/orders/482
GET /v2/orders/482हेडर-आधारित वर्ज़निंग
URI को स्थिर रखता है और वर्ज़न को कंटेंट-नेगोशिएशन के एक और आयाम की तरह मानता है — API शुद्धतावादियों की पसंद, पर ब्राउज़र बार या हाथ से curl में जाँचना कठिन।
GET /orders/482 HTTP/1.1
Accept: application/vnd.example.v2+jsonजो भी चुनें, ओवरलैप सपोर्ट करें
पुराने वर्ज़न के लिए प्रकाशित डिप्रिकेशन तारीख के साथ कम से कम दो वर्ज़न साथ-साथ चलाएँ — बिना माइग्रेशन विंडो के रातोंरात वर्ज़न न पलटें।
त्वरित जाँच: इनमें से कौन-सा API बदलाव *ब्रेकिंग* है जिसके लिए नए वर्ज़न की ज़रूरत होगी?
- रिस्पॉन्स में एक नया वैकल्पिक फ़ील्ड जोड़ना
- किसी मौजूदा रिस्पॉन्स फ़ील्ड का नाम बदलना
- एक नया एंडपॉइंट जोड़ना
- Documentation में typo ठीक करना
Answer
किसी मौजूदा रिस्पॉन्स फ़ील्ड का नाम बदलना — फ़ील्ड का नाम बदलना या हटाना पुराना नाम पढ़ने वाले किसी भी क्लाइंट को तोड़ देता है; नए फ़ील्ड या एंडपॉइंट जैसे एडिटिव बदलाव आमतौर पर सुरक्षित होते हैं।