मुख्य API versioning strategies कोणत्या आहेत, आणि एखादे version deprecate कसे करता?

Question

IT Interview Practice · Accepted Answer

Versioning तुम्हाला विद्यमान clients न मोडता **breaking changes** सह API विकसित करू देते. तीन मुख्य प्रवाहातील strategies आहेत, अधिक एक deprecation प्रक्रिया.

## तीन strategies

**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
```
URLs स्वच्छ ठेवते पण 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 असते), पण consumers साठी सर्वात कमी सुलभ.

## 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 सध्याच्यात जोडा.

## Deprecation प्रक्रिया

1. docs आणि changelog मध्ये तारखांसह **जाहीर करा (Announce)**.
2. clients ना programmatically लक्षात यावे म्हणून headers सह **runtime ला signal द्या**:
```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 चा वापर **Monitor करा** आणि उरलेल्या callers शी संपर्क साधा.
4. वापर जवळपास शून्यावर आल्यावरच **Sunset करा**.

## हे का महत्त्वाचे आहे

Interviewers हे पाहण्यासाठी विचारतात की तुम्ही production मध्ये API वर अवलंबून असणाऱ्या clients ना न मोडता वाढवू शकता का — एक खरी operational चिंता, सैद्धांतिक नव्हे. सर्वात मजबूत उत्तरे दोन फरक करतात: पहिला, **बहुतांश changes non-breaking असतात** आणि त्यांनी version bump अजिबात ट्रिगर करू नये (additive changes सध्याच्या version मध्ये जातात), versioning फक्त खऱ्या breaking changes साठी राखून ठेवा; आणि दुसरा, *strategy* पेक्षा *process* कमी महत्त्वाची नसते — `Deprecation`/`Sunset` headers आणि usage monitoring सह स्पष्ट deprecation timeline हेच खरे consumers चे रक्षण करते. URI versioning त्याच्या दृश्यमानतेमुळे आणि tooling support मुळे प्रत्यक्षात जिंकते, पण trade-offs माहीत असणे (header आणि media-type URLs स्थिर ठेवतात आणि अधिक RESTful असतात, discoverability च्या किंमतीवर) दर्शवते की तुम्ही फक्त `/v1/` ची नक्कल करण्याऐवजी design space समजता.

तीन strategies

breaking काय मानले जाते

Deprecation प्रक्रिया

हे का महत्त्वाचे आहे

संबंधित प्रश्न