耗时半年，Eoapi 终于正式发布 API 管理工具的插件广场 api接口

这是我们的第一篇月报，每个月和每个来之不易的开发者分享产品故事以及产品进展。
在 5.20 这个极具中国特色的“节日”里，Eoapi 发布了 1.0.0 版，三个程序员掉了半年头发堆出了第一个正式版本。
把 Eoapi 介绍给大家的过程中，我们遇到的最多问题是：
你和 Postman 有什么区别？
Postman 出现的时间，是八年前，几乎是同类型 API 工具的祖师爷。
毋庸置疑它是一款优秀的产品，在那个使用 Curl、浏览器、抓包工具调试 API 的年代，这款支持通过界面对 API 发起测试的工具令人眼前一亮。
那我们为什么还要做 Eoapi 呢？ 1. 商业工具不够开放
商业工具不够开放，除非官方支持，否则很难和其他平台打通。
理想中的用户每天都在使用我们的产品解决任何问题，而实际上用户每天会和各种不同的工具打交道，并没有足够多的时间专注在使用你的产品。

文章图片

△ by Jonathan Holt @ Dribbble
所以足够简单，同时打磨核心功能，定义好产品的边界很重要。
我们不想做一个 All in one 的工具，如果没法满足用户的所有需求，那就足够开放让用户选择按照他们喜欢的方式使用各个产品。
没有什么能比代码开源更开放了！
所以从去年 11 月开始，我们开始立项、组团队开始做 Eoapi。

文章图片

下方截图是我们的第一个用户，我在调研时问他：你期待的 API 工具是什么样子？
他回答：希望各个工具不要做数据孤岛，能连通多个产品。

文章图片

需要开发者自己写工具连通
如果说代码开源是我们开放的第一步，那第二步就是加入插件系统了。
如果只是代码开源，想要拓展功能仍然比较困难，我知道很多团队会选择在源代码的基础上二次开发，但当选择二次开发的那一刻起，可能就和后续的官方更新 say goodbye 了，对用户和官方来说都是一种损失，而插件系统就是解决这个问题的一个很好的方案。
插件系统让开发者群体——一群极具创造力的人以更简单的方式参与共建，扩展功能、复用功能、碰撞更多可能。
2. 团队需要本地部署
商业产品数据一般放在云端，考虑到安全性，国内大多数公司会将 API 托管在自己平台，有资源的大公司造轮子，没资源的小团队使用开源工具。
Eoapi 可以单机使用，数据存储到本地，也支持在自己的服务器远程数据源，你完全可以把数据掌握在自己手里。
3. 更流畅的协作
Postman 功能比较垂直，单点功能设计很棒，但实际用于团队协作时功能操作逻辑不够连贯，也不够贴合国人开发协作场景。
国外的需求更偏向个体效率，而国内的需求更偏向于管理效率。如何在满足个体效率的同时贴合国内的管理效率，这是 Eoapi 想要找到的平衡。
我们不会说 Eoapi 是一款针对中国开发者研发的产品，我们的用户是所有开发者，不分国界。
我心目中真正好的 API 工具，远不止调试，还可以让开发者：