Architecture Decision Record架構決策記錄:REST API 使用 snake_case 還是 camelCase?
決策:REST API 端點將使用 snake_case 命名約定
狀態:已接受
背景
在 REST API 的命名約定中,有兩種流行的格式:snake_case 和 camelCase。snake_case 格式是名稱中的每個單詞用下劃線分隔,而 camelCase 是名稱的第一個單詞小寫,後續單詞的首字母大寫。這項決策將確定 REST API 應使用哪種命名約定。
決策驅動因素
與專案中現有命名約定的一致性
對任何可能參與 API 工作的人而言的可讀性和清晰度
與 REST API 命名約定的行業最佳實踐保持一致
易於實現和維護
決策
REST API 端點將使用 snake_case 命名約定。這一選擇由以下因素驅動:
一致性:專案已經對所有端點使用 snake_case 命名約定,保持這一約定將有利於確保整個專案的一致性。
可讀性和清晰度:snake_case 約定更易讀、更易於理解。下劃線使單詞之間有清晰的分隔,更容易解析和理解名稱的含義。
與行業最佳實踐保持一致:snake_case 約定在業界被廣泛使用,並被認為是 REST API 的最佳實踐,因此是該專案的良好選擇。
易於實現和維護:沿用現有的命名約定更易於實現和維護,因為如果選擇新的約定,所有現有的程式碼和文件都需要更新。
後果
這項決策存在一些潛在後果。
如果加入專案的新團隊成員不熟悉 snake_case 命名約定,可能會導致混淆和開發中的錯誤。不過,由於 snake_case 是一種被廣泛使用的約定,這種風險極小。
如果專案中使用了嚴重依賴 camelCase 約定的其他工具或框架,可能需要額外的工作來在命名約定之間進行轉換。不過,由於專案已將 snake_case 約定標準化,這並不是一個重大問題。
總體而言,為 REST API 端點使用 snake_case 命名約定的決策,帶來了一種一致、可讀且符合行業標準的方法,同時易於實現和維護。