在任何初创公司中，跨多个服务管理 api 是一个常见的挑战。
我们面临三个主要问题：
记录 api发布文档每当 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 扩展。它具有使我们的工作流程更加顺畅的功能：
直接在编辑器中执行.l2文件复制文件的 git url 以便于共享美化 json 负载从 .l2 语法生成任何语言的代码片段在几秒钟内为新 api 创建模板使用 lsp 自动完成变量
这个扩展很快就成为团队的最爱，我们决定将其发布在 github 上，以便其他人也能受益。
下一个问题：扩展文档
随着我们的 api 不断增长，我们问自己：
为什么要手动记录每个服务的 api？每次更改都更新文档不是很耗时吗？
这就是我们旅程的下一章开始的地方……
关注我，了解我的下一篇文章接下来会发生什么。
以上就是Hobby API 收集和执行工具如何演变成产品的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1499427.html
微信扫一扫 
支付宝扫一扫 
