如何免費調用有道翻譯API實現多語言翻譯
![規則：schema-names-pascal-case：描述：模式名稱必須以 PascalCase 格式書寫消息：'{{property}} 不是 PascalCase：{{error}}' 推薦：true 類型：style 給定：'$.components.schemas.~' 然后：功能：模式 functionOptions：匹配：'^[AZ][a-zA-Z0-9]$'](https://stoplightblog.wpenginepowered.com/wp-content/uploads/2023/11/custom-rules-1.png)
您可以使用 Spectral 創建規則集，這些規則集可以具有自定義規則甚至自定義功能！
這些自定義規則看起來有點像這樣：
這個比較流行。OpenAPI 并不關心你如何將模型首字母大寫，但很多代碼生成器會使用模型名稱來編寫代碼，而不一致的類名會讓人不爽。
讓我們更進一步：
![規則：paths-kebab-case：描述：路徑是否應為 kebab-case。消息：'{{property}} 不是 kebab-case：{{error}}'嚴重性：警告推薦：true 給定：$.paths[*]~ 然后：功能：模式 functionOptions：匹配：“^(/[a-z0-9-{}]+)+$”](https://stoplightblog.wpenginepowered.com/wp-content/uploads/2023/11/one-step-further-1.png)
此規則實際上超越了 API 描述的元數據，而是著眼于實際的 API 設計本身。這意味著“路徑”（接口）必須帶連字符，因此/recent-files是可以的，但/recent_files不行。
您可以開始真正發揮創造力。
![規則：no-x-headers：描述：“請不要使用帶有 X- 的標題”消息：“標題不能以 X- 開頭，因此請為 {{property}} 找到一個新名稱。更多信息：https://tools.ietf.org/html/rfc6648”推薦：true 給定：“$..parameters.[?(@.in === 'header')].name”然后：功能：模式 functionOptions：notMatch：'^(x|X)-'](https://stoplightblog.wpenginepowered.com/wp-content/uploads/2023/11/creative-1.png)
我不知道為什么，但在任何給定 API 的生命周期的某個時刻，一些開發人員會建議添加 X-Foo 標頭，盡管十多年來它一直導致問題。好吧，我們可以用這條規則把他們拒之門外。
如果盡早完成，這將在開發過程中塑造實際的 API。如果您先編寫代碼，那么好吧，您必須返回并更改一堆代碼。希望您沒有發布它，因為現在您需要為/recent_files /recent_files進行大量重定向。如果您使用API 設計優先工作流程，那么當您剛剛獲得一些 YAML 時，您會盡早注意到這一點，并且您的 API 首先得到構建。
由于 Spectral 是一個 CLI/JS 工具，因此可以通過各種方式來執行此樣式指南。
如果您使用Stoplight Studio，那么它就會直接嵌入到編輯器中，因此設計 API 的人可以立即正確完成所有操作。無需按 Alt-Tab 鍵轉到 CLI 或等到 PR 完成。
我正在努力抽出時間從Heroku或PayPal獲取樣式指南，并將它們轉換成一個巨大的示例規則集。至少，我可以從中汲取一些靈感，用于我正在整理的新規則集：OpenAPI Contrib > 樣式指南。這應該是一個有趣的社區努力。
Spectral 還有一個GitHub Action，我們正在努力改進它。評論范圍和建議即將推出！
GraphQL 有自己的內置類型系統，其中有一些與基于 OpenAPI / JSON Schema 相同類型的關鍵字。
GraphQL 使一些設計決策變得更容易，比如如何處理關系。無需在嵌套/嵌入相關資源、使用復合文檔內聯所有內容或使用超鏈接鏈接到相關數據之間做出選擇，GraphQL 會為您做出決定。盡管如此，在 GraphQL 做出的默認決策之外，仍可能出現許多不一致的情況。GraphQL 人員無法逃避 lint 的需要，但幸運的是，存在一個很棒的 linter：GraphQL Schema Linter。
也可以為此編寫自定義規則，這樣您就可以在 CI 中自動化您的樣式指南。我看不到機器人或 GitHub Action，但它們并不難組合在一起。
GraphQL 領域中一款擁有出色機器人的架構工具是 GraphQL Doctor。它似乎希望在總體上提供更多幫助，但到目前為止，它專注于檢測重大更改。與任何類型的系統一樣，謹慎發展和魯莽更改之間存在一條細線，而 GraphQL Doctor 會發現后者。
如果這兩個工具能夠合并就好了，或者 GraphQL Doctor 機器人可以支持 GraphQL Schema Linter，但就目前而言，它是一個兩站式商店。
Google 在 API 領域做了一些非常有趣的工作。他們是 API 領域首批不斷解釋“有時你需要 REST，有時你需要 RPC”的大公司之一，并且他們堅持使用適用于gRPC 和 HTTP 的通用工具。API linter 在 protobuf 表層上運行，但可以設置為與 HTTP 端點一起工作：
使用協議緩沖區時，每個 RPC 都必須使用 google.api.http 注釋定義 HTTP 方法和路徑：
API Linter 的核心規則集相當令人印象深刻，它重點關注 HTTP 規范中不太清楚的尷尬部分。例如，GET 應該有一個主體嗎？答案是“也許可以”，但很可能沒有，這取決于你正在構建的工具，呃。求助。
谷歌決定直接回答：不。
他們還決定說服團隊從 proto2 升級到 proto3。
您可以使用這些東西自動化幾乎任何事情，并且我一直在思考許多超越強制命名或復數化的常見用例的規則。
這些規則中有許多是特定于 HTTP API 的，但您明白我的意思。隨著時間的推移，我將研究其中一些規則，并將它們添加到 OpenAPI Contrib 的樣式指南中，如果您愿意做出貢獻，我很樂意在 GitHub 上指導您完成整個過程。
如果您聽說過 API 治理這個術語，那么大多數人都在談論這個術語。目前，許多試圖進行治理的人都在仔細查看每個 PR 上的 API 描述，并培訓人們記住他們提出的所有質量規則。
手動 API 培訓是一項吃力不討好、效率低下、永無止境的任務，它可以被編輯器、git hook、CI 管道、GitHub Action 或機器人中嵌入的 linter 所取代（或大幅簡化）。
不要浪費客戶的時間強迫他們嘗試找出您的不一致之處。不要浪費所有 API 開發人員的時間來學習記住樣式指南。不要浪費 API 管理團隊的時間來手動審查 API。不要浪費每個人的時間來修復生產中的不一致之處。
原文鏈接：Automated?Style?Guides?for?REST,?GraphQL?and?gRPC
