REST API Versioning

本來對API分版號有個大概的印象，不外乎是邏輯、res 有了異動，但確切是為了什麼？又有哪些切版方式呢？我找到了這篇文章，讀完之後，我理解到重點不是怎麼切，而是怎麼管理變動，又可以確保API 使用的一至性

以下為整理之重點

1. 什麼時候要升API版本呢？

   重大變動時刻，包含以下三種情況

   • response 格式異動
   • request 格式異動
   • API 移除了任一部分

   其實開發過程中不免會有陸續的變動，但我想以上屬於大致情況，我認為是當需求有所變動，而既有的API所提供的內容已經不敷使用、但又有一些情況會用到，那麼這時候可以選擇切版，關鍵是 重大變動＋有不能更新既有版本API的情況

2. 有哪些方式可以升API 版本呢？

   1. URI （最常用情況，通常是v[x],x 為版號數字）
   2. Custom Request Header 客製化表頭 （建立一專屬表頭，作為識別用）
   3. Accept Header （合併在 accept 表頭中）

總結，其實怎麼做切版通常不是重點，因為就只是一個flag作為辨識用而已，但真的有挑戰的是，多少的變動，應該切版，這個決策的過程，如作者提到的管理變動，讓API呈現一至性的體驗，不會因為升版，而倒置既API 出現問題