મુખ્ય API versioning વ્યૂહરચનાઓ કઈ છે, અને version ને કેવી રીતે deprecate કરો છો?

Question

IT Interview Practice · Accepted Answer

Versioning તમને હાલના clients ને તોડ્યા વગર **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
```
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      → field દૂર/નામ બદલવું, type બદલવો, auth બદલવો, validation કડક કરવું
NON-BREAKING  → નવું optional field ઉમેરવું, નવો endpoint ઉમેરવો, enum value ઉમેરવી*
```
ફક્ત breaking changes ને નવું version જોઈએ; non-breaking changes ને વર્તમાનમાં ઉમેરો.

## Deprecation પ્રક્રિયા

1. docs અને changelog માં તારીખો સાથે **જાહેર કરો**.
2. clients programmatically ધ્યાનમાં લે એ માટે 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 નો ઉપયોગ **monitor કરો** અને બાકીના callers નો સંપર્ક કરો.
4. ઉપયોગ શૂન્યની નજીક પડે પછી જ **Sunset** કરો.

## આ શા માટે મહત્વનું છે

Interviewers આ પૂછે છે એ જોવા કે તમે તેના પર આધારિત clients ને તોડ્યા વગર production માં API વધારી શકો છો કે નહીં — વાસ્તવિક 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 સમજો છો.

ત્રણ વ્યૂહરચનાઓ

breaking તરીકે શું ગણાય

Deprecation પ્રક્રિયા

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો