প্রধান API versioning কৌশলগুলো কী কী, এবং আপনি কীভাবে একটি version deprecate করেন?

Question

IT Interview Practice · Accepted Answer

Versioning আপনাকে বিদ্যমান client না ভেঙে **breaking change** সহ একটি 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-এর এখন দুটি URL)। এটি এখন পর্যন্ত সবচেয়ে সাধারণ পছন্দ (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** — `Accept`-এ version।
```http
GET /users/42 HTTP/1.1
Accept: application/vnd.example.v2+json
```
সবচেয়ে "RESTful" (resource URL স্থিতিশীল; শুধু এর representation versioned), কিন্তু consumer-দের জন্য সবচেয়ে কম সহজলভ্য।

## কোনটি 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 change-এর জন্য একটি নতুন version দরকার; non-breaking change বর্তমানটিতে যোগ করুন।

## Deprecation প্রক্রিয়া

1. docs আর changelog-এ তারিখ সহ **ঘোষণা করুন**।
2. Header দিয়ে **runtime-এ সংকেত দিন** যাতে client প্রোগ্রামগতভাবে লক্ষ্য করে:
```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-এর ব্যবহার **নিরীক্ষণ করুন** এবং বাকি caller-দের কাছে পৌঁছান।
4. ব্যবহার শূন্যের কাছাকাছি নামলে তবেই **Sunset** করুন।

## এটি কেন গুরুত্বপূর্ণ

Interviewer-রা এটি জিজ্ঞেস করেন দেখতে আপনি production-এ একটি API বাড়াতে পারেন কিনা এর ওপর নির্ভরশীল client না ভেঙে — একটি বাস্তব operational উদ্বেগ, তাত্ত্বিক নয়। সবচেয়ে শক্তিশালী উত্তর দুটি পার্থক্য টানে: প্রথমত, **বেশিরভাগ change non-breaking** এবং মোটেই একটি version bump ট্রিগার করা উচিত নয় (additive change বর্তমান version-এ যায়), সত্যিকারের breaking change-এর জন্য versioning সংরক্ষিত রেখে; এবং দ্বিতীয়ত, *কৌশল*-এর চেয়ে *প্রক্রিয়া* বেশি গুরুত্বপূর্ণ — `Deprecation`/`Sunset` header ও ব্যবহার নিরীক্ষণ সহ একটি পরিষ্কার deprecation timeline-ই আসলে consumer-দের রক্ষা করে। URI versioning তার দৃশ্যমানতা ও tooling সমর্থনের জন্য বাস্তবে জেতে, কিন্তু ট্রেড-অফ জানা (header আর media-type URL স্থিতিশীল রাখে এবং বেশি RESTful, discoverability-র বিনিময়ে) দেখায় আপনি শুধু `/v1/` অনুকরণ না করে design space বোঝেন।

তিনটি কৌশল

কোনটি breaking হিসেবে গণ্য

Deprecation প্রক্রিয়া

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন