# v1 और v2 को साथ-साथ चलाना — API Design और Versioning

Source: https://www.geekswithgeeks.com/hi/api-design/ver-v1-v2-example

> देखें कि 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`)।

```python
# 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
```

**Quiz:** कई API versions के लिए एक आंतरिक मॉडल क्यों रखें?

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

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