ਮੁੱਖ API versioning strategies ਕੀ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਇੱਕ version ਨੂੰ deprecate ਕਿਵੇਂ ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

Versioning ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ clients ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ **breaking changes** ਨਾਲ ਇੱਕ API ਵਿਕਸਤ ਕਰਨ ਦਿੰਦੀ ਹੈ। ਤਿੰਨ ਮੁੱਖਧਾਰਾ strategies ਹਨ, ਨਾਲ ਇੱਕ deprecation process।

## ਤਿੰਨ 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 ਹੈ), ਪਰ ਖਪਤਕਾਰਾਂ ਲਈ ਸਭ ਤੋਂ ਘੱਟ ਪਹੁੰਚਯੋਗ।

## 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 process

1. docs ਅਤੇ changelog ਵਿੱਚ ਤਾਰੀਖਾਂ ਨਾਲ **ਐਲਾਨ ਕਰੋ**।
2. headers ਨਾਲ **runtime 'ਤੇ ਸੰਕੇਤ ਦਿਓ** ਤਾਂ ਜੋ clients ਪ੍ਰੋਗਰਾਮੀ ਤੌਰ 'ਤੇ ਧਿਆਨ ਦੇਣ:
```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** ਸਿਰਫ਼ ਉਦੋਂ ਕਰੋ ਜਦੋਂ ਵਰਤੋਂ ਲਗਭਗ ਸਿਫ਼ਰ 'ਤੇ ਆ ਜਾਵੇ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲੇ ਇਹ ਦੇਖਣ ਲਈ ਪੁੱਛਦੇ ਹਨ ਕਿ ਕੀ ਤੁਸੀਂ production ਵਿੱਚ ਇੱਕ API ਨੂੰ ਇਸ 'ਤੇ ਨਿਰਭਰ clients ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਵਧਾ ਸਕਦੇ ਹੋ — ਇੱਕ ਅਸਲੀ ਸੰਚਾਲਨ ਚਿੰਤਾ, ਨਾ ਕਿ ਸਿਧਾਂਤਕ। ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਜਵਾਬ ਦੋ ਭੇਦ ਬਣਾਉਂਦੇ ਹਨ: ਪਹਿਲਾ, ਕਿ **ਬਹੁਤੇ changes non-breaking ਹਨ** ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਇੱਕ version bump ਬਿਲਕੁਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ (additive changes ਮੌਜੂਦਾ version ਵਿੱਚ ਜਾਂਦੇ ਹਨ), versioning ਨੂੰ ਸੱਚਮੁੱਚ breaking changes ਲਈ ਰਾਖਵਾਂ ਰੱਖਦੇ ਹੋਏ; ਅਤੇ ਦੂਜਾ, ਕਿ *strategy* *process* ਨਾਲੋਂ ਘੱਟ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ — `Deprecation`/`Sunset` headers ਅਤੇ ਵਰਤੋਂ ਦੀ ਨਿਗਰਾਨੀ ਨਾਲ ਇੱਕ ਸਪਸ਼ਟ deprecation timeline ਹੀ ਉਹ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਖਪਤਕਾਰਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। URI versioning ਅਮਲ ਵਿੱਚ ਆਪਣੀ ਦਿੱਖਣਯੋਗਤਾ ਅਤੇ tooling ਸਹਾਇਤਾ ਲਈ ਜਿੱਤਦੀ ਹੈ, ਪਰ trade-offs ਜਾਣਨਾ (header ਅਤੇ media-type URLs ਸਥਿਰ ਰੱਖਦੇ ਹਨ ਅਤੇ ਵੱਧ RESTful ਹਨ, discoverability ਦੀ ਕੀਮਤ 'ਤੇ) ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਰਫ਼ `/v1/` ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ design space ਨੂੰ ਸਮਝਦੇ ਹੋ।

ਤਿੰਨ strategies

breaking ਕੀ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ

Deprecation process

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ