ప్రధాన API versioning వ్యూహాలు ఏమిటి, ఒక versionను ఎలా deprecate చేస్తారు?

Question

IT Interview Practice · Accepted Answer

Versioning ఇప్పటికే ఉన్న clientలను విచ్ఛిన్నం చేయకుండా **breaking changes**తో ఒక APIను అభివృద్ధి చేయనిస్తుంది. మూడు ప్రధాన వ్యూహాలు, ఒక deprecation ప్రక్రియ ఉన్నాయి.

## మూడు వ్యూహాలు

**1. URI versioning** — version pathలో ఉంటుంది.
```http
GET /v1/users/42 HTTP/1.1
GET /v2/users/42 HTTP/1.1
```
అత్యంత సరళం, అత్యంత కనిపించేది; route, cache, browserలో test చేయడం సులభం. ప్రతికూలత: ఇది సాంకేతికంగా "URI ఒక resourceను గుర్తిస్తుంది"ను ఉల్లంఘిస్తుంది (అదే userకు ఇప్పుడు రెండు URLs). ఇది ఎంతో సాధారణ ఎంపిక (GitHub, చారిత్రకంగా Stripe).

**2. Custom header versioning** — version ఒక headerలో ప్రయాణిస్తుంది.
```http
GET /users/42 HTTP/1.1
X-API-Version: 2
```
URLలను శుభ్రంగా ఉంచుతుంది కానీ browserలో అదృశ్యం, cache చేయడం కష్టం.

**3. Media-type (content negotiation) versioning** — version `Accept`లో.
```http
GET /users/42 HTTP/1.1
Accept: application/vnd.example.v2+json
```
అత్యంత "RESTful" (resource URL స్థిరం; దాని representation మాత్రమే versioned), కానీ vinియోగదారులకు అత్యంత కష్టమైనది.

## breaking అంటే ఏమిటి

```text
BREAKING      → remove/rename a field, change a type, change auth, tighten validation
NON-BREAKING  → add a new optional field, add a new endpoint, add an enum value*
```
Breaking changesకు మాత్రమే కొత్త version అవసరం; non-breaking changesను ప్రస్తుత versionకు జోడించండి.

## Deprecation ప్రక్రియ

1. docs మరియు changelogలో తేదీలతో **ప్రకటించండి**.
2. clientలు ప్రోగ్రామాటిక్‌గా గమనించేలా headersతో **runtimeలో సంకేతం ఇవ్వండి**:
```http
HTTP/1.1 200 OK
Deprecation: true
Sunset: Sat, 31 Jan 2026 23:59:59 GMT
Link: <https://api.example.com/v2/users/42>; rel="successor-version"
```
3. పాత version వాడకాన్ని **పర్యవేక్షించండి**, మిగిలిన callersను సంప్రదించండి.
4. వాడకం దాదాపు సున్నాకు పడిపోయిన తర్వాత మాత్రమే **Sunset** చేయండి.

## ఇది ఎందుకు ముఖ్యం

దానిపై ఆధారపడే clientలను విచ్ఛిన్నం చేయకుండా మీరు productionలో ఒక APIను పెంచగలరో లేదో చూడటానికి ఇంటర్వ్యూయర్‌లు దీన్ని అడుగుతారు — ఇది ఒక సైద్ధాంతిక కాదు, నిజమైన కార్యాచరణ ఆందోళన. బలమైన జవాబులు రెండు తేడాలు చేస్తాయి: మొదటిది, **చాలా changes non-breaking** మరియు అస్సలు version bumpను ప్రేరేపించకూడదు (additive changes ప్రస్తుత versionలోకి వెళ్తాయి), versioningను నిజంగా breaking changesకు మాత్రమే కేటాయించడం; రెండవది, *వ్యూహం* కంటే *ప్రక్రియ* ముఖ్యం — `Deprecation`/`Sunset` headers మరియు usage monitoringతో ఒక స్పష్టమైన deprecation timeline నిజంగా vinియోగదారులను రక్షిస్తుంది. URI versioning దాని కనిపించే గుణం, tooling మద్దతు వల్ల ఆచరణలో గెలుస్తుంది, కానీ ట్రేడ్-ఆఫ్‌లు (header మరియు media-type URLలను స్థిరంగా ఉంచుతాయి, ఎక్కువ RESTful, discoverability ఖర్చుతో) తెలుసుకోవడం మీరు కేవలం `/v1/`ను అనుకరించడం కాకుండా డిజైన్ స్థలాన్ని అర్థం చేసుకున్నారని చూపుతుంది.

మూడు వ్యూహాలు

breaking అంటే ఏమిటి

Deprecation ప్రక్రియ

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు