पाठ 19 / 27

v1 और v2 को साथ-साथ चलाना

देखें कि v2 के response आकार में सुधार करते हुए दो versions साथ कैसे रह सकते हैं।

एक डेटा मॉडल, दो प्रतिनिधित्व

नए version का आम कारण बेहतर प्रतिनिधित्व है। Demo API में v1 ने एक name string लौटाई; v2 उसे first_name और last_name में बाँटता है, जो name पढ़ने वाले clients के लिए तोड़ने वाला बदलाव है। Server एक आंतरिक मॉडल और दो पतले serialisers रखता है, इसलिए दोनों versions एक ही डेटा से परोसे जाते हैं और नई सुविधाएँ दो बार बनानी नहीं पड़तीं। Clients के v2 पर जाने तक v1 उपलब्ध रहता है, deprecated और sunset तारीख़ के साथ चिह्नित।

v1 (deprecated) और v2 responses, चलाकर

मैंने यह केवल Python standard library से बने छोटे असली HTTP API पर चलाया (पूरा कोड केस स्टडी में)। v1 name लौटाता है और Deprecation, Sunset तथा उत्तराधिकारी version का Link जोड़ता है। v2 बँटे fields लौटाता है और कोई deprecation header नहीं (None)।

# uses srv, base and call() from the runnable demo in the case study
s, h, b = call("GET", "/v1/items/1"); print(s, b, h.get("Deprecation"), h.get("Sunset")); print(h.get("Link"))
s, h, b = call("GET", "/v2/items/1"); print(s, b, h.get("Deprecation"))

Output:

200 {'id': 1, 'name': 'Asha Rao', 'plan': 'pro'} true Wed, 31 Dec 2026 23:59:59 GMT
</v2/items/1>; rel="successor-version"
200 {'id': 1, 'first_name': 'Asha', 'last_name': 'Rao', 'plan': 'pro'} None

त्वरित जाँच: कई API versions के लिए एक आंतरिक मॉडल क्यों रखें?

  • यह tests की ज़रूरत हटाता है
  • यह clients को upgrade करने पर मजबूर करता है
  • कई models हमेशा ज़रूरी हैं
  • सुविधाएँ और सुधार एक बार बनते हैं और version-विशिष्ट serialisers से उपलब्ध होते हैं
Answer

सुविधाएँ और सुधार एक बार बनते हैं और version-विशिष्ट serialisers से उपलब्ध होते हैं — पतली अनुवाद परतें पुराने और नए आकार साथ रहने पर दोहराव सीमित करती हैं।