REST API 設計規範：如何讓團隊不再為 camelCase 還是 snake_case 吵架？自動化 Style Guide 才是解藥
開發會議上的「不停內耗」 身為技術主管或資深工程師，您一定經歷過這種場景： 在 Code Review 會議上，兩個工程師爭得面紅耳赤。 A 說：「API 欄位應該要用駝峰式命名 (camelCase)，像 userId！」 B 說：「不對！資料庫欄位是底線式 (snake_case)，API 應該要對應，用 user_id！」 C 默默舉手：「那個…你們有沒有發現他的 Error Code 回傳是 200 OK 但是內容寫 ‘Failed’？」 這些關於「風格」與「規範」的爭論，往往消耗了團隊大量的時間，卻對業務邏輯沒有直接幫助。但如果不統一，當這些 API 被前端或合作夥伴串接時，災難就發生了——沒有人知道這家公司的 API 到底該怎麼用。 今天我們要聊的，就是如何用「自動化工具」來終結這場不必要的內戰。 什麼是 API Style Guide (風格指南)？ 在程式碼的世界裡，我們有 ESLint 來檢查 JavaScript 語法；同樣的，在 API 設計的世界裡（OpenAPI/Swagger），我們也需要一套 API Style Guide，也就是 API 規範的風格指南。 它是一組定義明確的規則，例如： 命名慣例：所有的 URL Path 必須是小寫且用連字號分隔 (kebab-case)。 安全性：所有的 […]