後端改版，前端崩潰？用 API Versioning 與 Breaking Change 檢測終結「版本地獄」
週五下午的慘案 這是一個真實發生在許多團隊的故事： 週五下午四點，後端工程師小明心想：「這個 userAge 欄位好像沒在用了，而且我們已經有 birthDate 了，為了讓 API 乾淨一點，我把它刪掉好了。」 小明按下 Commit，開心下班過週末。 週五晚上七點，客服電話被打爆。所有舊版的 iOS App 用戶在開啟「個人頁面」時全部閃退。 原因很簡單：舊版 App 還在讀取 userAge，但這個欄位突然憑空消失，導致 App 解析 JSON 失敗 (Null Pointer Exception)。 這就是所謂的 Breaking Change (破壞性變更)。 在微服務與前後端分離的架構下，後端工程師往往無法精確知道「誰正在使用我的 API」。靠「通靈」或「口頭詢問」來判斷欄位能不能改，是極度危險的。 今天我們要聊聊，如何用 SmartBear Swagger (SwaggerHub) 來建立一道「防呆機制」。 什麼是 Breaking Change？ 簡單來說，就是「會讓客戶端 (Client) 出錯的變更」。 常見的破壞性變更包括： 刪除欄位：如上述案例。 修改欄位名稱：把 id 改成 userId。 修改資料型別：把字串 “123” 改成數字 123。 新增「必填」參數：原本呼叫不用參數，現在變成一定要傳參數才能動。 反之，如果是「新增一個非必填欄位」，通常被視為安全變更 […]