Apa strategi versioning API utama, lan kepiye carane nde-deprecate sawijining versi?

Question

IT Interview Practice · Accepted Answer

Versioning ngidini kowe ngembangake API kanthi **breaking change** tanpa ngrusak client sing wis ana. Ana telung strategi arus utama, ditambah proses deprecation.

## Telung strategi

**1. URI versioning** — versine ana ing path.
```http
GET /v1/users/42 HTTP/1.1
GET /v2/users/42 HTTP/1.1
```
Paling prasaja lan paling katon; gampang di-route, di-cache, lan dites ing browser. Kekurangane: sacara teknis nglanggar "URI ngidentifikasi resource" (user sing padha saiki duwe rong URL). Iki pilihan sing paling umum dhewe (GitHub, Stripe biyen).

**2. Custom header versioning** — versine mlaku ing header.
```http
GET /users/42 HTTP/1.1
X-API-Version: 2
```
Njaga URL tetep resik nanging ora katon ing browser lan luwih angel di-cache.

**3. Media-type (content negotiation) versioning** — versi ing `Accept`.
```http
GET /users/42 HTTP/1.1
Accept: application/vnd.example.v2+json
```
Sing paling "RESTful" (URL resource stabil; mung representasine sing di-versi), nanging paling angel diakses konsumen.

## Apa sing kalebu breaking

```text
BREAKING      → mbusak/ngganti jeneng field, ngganti tipe, ngganti auth, ngetatake validasi
NON-BREAKING  → nambah field optional anyar, nambah endpoint anyar, nambah nilai enum*
```
Mung breaking change sing butuh versi anyar; tambahake non-breaking change menyang versi saiki.

## Proses deprecation

1. **Umumake** kanthi tanggal ing dokumentasi lan changelog.
2. **Sinyal nalika runtime** nganggo header supaya client eruh kanthi programatis:
```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. **Pantau** panggunaan versi lawas lan hubungi caller sing isih ana.
4. **Sunset** mung sawise panggunaan mudhun cedhak nol.

## Kenapa iki penting

Pewawancara takon iki kanggo ndeleng apa kowe bisa ngembangake API ing produksi tanpa ngrusak client sing gumantung marang dheweke — perkara operasional nyata, dudu teoritis. Jawaban sing paling kuat nggawe rong bedan: kapisan, yen **umume owah-owahan iku non-breaking** lan ora kudu micu bump versi babar pisan (owah-owahan tambahan mlebu versi saiki), nyimpen versioning kanggo breaking change sing tenanan; lan kapindho, yen *strategi* kurang penting tinimbang *proses* — timeline deprecation sing cetha kanthi header `Deprecation`/`Sunset` lan monitoring panggunaan iku sing tenanan ngayomi konsumen. URI versioning menang ing praktik amarga katon lan didhukung tooling, nanging ngerti trade-off-e (header lan media-type njaga URL tetep stabil lan luwih RESTful, kanthi biaya keterbukaan) nuduhake yen kowe mangerteni ruang desain tinimbang mung niru `/v1/`.

Telung strategi

Apa sing kalebu breaking

Proses deprecation

Kenapa iki penting

Pitakon sing gegandhengan