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中文网其他相关文章！