முக்கிய 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 மட்டுமே version செய்யப்படுகிறது), ஆனால் நுகர்வோருக்கு மிகக் குறைவாக அணுகக்கூடியது.

## எது 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. Clients நிரல்ரீதியாக கவனிக்க 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** செய்யவும்.

## இது ஏன் முக்கியம்

அதைச் சார்ந்திருக்கும் clients-ஐ உடைக்காமல் production-இல் ஒரு API-ஐ வளர்க்க முடியுமா என்று பார்க்க interviewers இதைக் கேட்கிறார்கள் — ஒரு உண்மையான operational கவலை, தத்துவார்த்தமானது அல்ல. வலுவான பதில்கள் இரண்டு வேறுபாடுகளைச் செய்கின்றன: முதலில், **பெரும்பாலான changes non-breaking** மற்றும் ஒரு version bump-ஐத் தூண்டவே கூடாது (additive changes தற்போதைய version-க்குள் செல்கின்றன), உண்மையான breaking changes-க்கு versioning-ஐ ஒதுக்குதல்; இரண்டாவதாக, *strategy* விட *process* முக்கியம் — `Deprecation`/`Sunset` headers மற்றும் usage monitoring கொண்ட ஒரு தெளிவான deprecation timeline தான் உண்மையில் நுகர்வோரைப் பாதுகாக்கிறது. URI versioning அதன் தெரிவுத்தன்மை மற்றும் tooling ஆதரவால் நடைமுறையில் வெல்கிறது, ஆனால் trade-offs-ஐ அறிவது (header மற்றும் media-type URLs-ஐ நிலையாகவும் RESTful-ஆகவும் வைக்கின்றன, discoverability-ஐ இழந்து) நீங்கள் வெறுமனே `/v1/`-ஐப் பின்பற்றாமல் design space-ஐப் புரிந்துகொள்கிறீர்கள் என்பதைக் காட்டுகிறது.

மூன்று strategies

எது breaking ஆகக் கருதப்படுகிறது

Deprecation செயல்முறை

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்