Hobby API 收集和執行工具如何演變成產品

在任何新創公司中，跨多個服務管理 API 是一個常見的挑戰。

我們面臨三個主要問題：

1. 記錄 API
2. 發布文件
3. 每當 API 變更時進行更新

每一個都有自己的一系列問題：如何做、在哪裡做、使用什麼工具以及誰將擁有所有權。

為了解決這個問題，我們的團隊決定將所有 API 合併到一個名為 APIHub 的儲存庫中。每個服務的 API 都以簡單且一致的格式儲存：

GET | POST | PUT | DELETE | PATCH  
${baseurl}/endpoint  
{  
  "body": "if present"  
}

我們根據文件的功能命名它們。以下是「Leave Apply」API 的 .l2 檔案範例，以及顯示儲存庫中其他 API 的側邊欄：

改進文件實踐

我們強制要求在每個拉取/合併請求中包含相應的 .l2 檔案。如果不存在，該請求將不會被批准。這個簡單的規則提高了整個團隊的 API 文件一致性。

從文件到執行

我們很快就意識到，透過將 URL 和有效負載複製到 Postman 等工具來手動測試 API 非常耗時。因此，我們建構了一個名為 Lama2.

的 CLI 工具 Lama2 是一個純文字 API 管理器，針對基於 Git 的協作進行了最佳化。

使用 Lama2，您可以傳遞 .l2 檔案作為輸入，CLI 將執行 API 並在終端機中顯示回應：

這使我們免於不斷地複製貼上，但切換目錄來查找 .l2 檔案仍然很乏味：

lovestaco@i3nux:~/apihub/feedback/fb_v3/leave$ l2 apply_leave.l2  

將其帶到 VSCode

為了進一步簡化事情，我們開發了 VSCode 擴充。它具有使我們的工作流程更加順暢的功能：

1. 直接在編輯器中執行.l2文件
2. 複製檔案的 Git URL 以便於共享
3. 美化 JSON 負載
4. 從 .l2 語法產生任何語言的程式碼片段
5. 在幾秒鐘內為新 API 建立模板
6. 使用 LSP 自動完成變數

這個擴充很快就成為團隊的最愛，我們決定將其發佈在 GitHub 上，以便其他人也能受益。

下一個問題：擴充文檔

隨著 API 的成長，我們問自己：

• 為什麼要手動記錄每個服務的 API？
• 每次更改都更新文件不是很耗時嗎？

這就是我們旅程的下一章開始的地方...
關注我，了解我的下一篇文章接下來會發生什麼。

以上是Hobby API 收集和執行工具如何演變成產品的詳細內容。更多資訊請關注PHP中文網其他相關文章！