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？
• 每次更改都更新文档不是很耗时吗？

这就是我们旅程的下一章开始的地方……
关注我，了解我的下一篇文章接下来会发生什么。