传统维护文档方式
1.word格式文档
2.在线markdown文本
API管理的痛点
- API接口在设计时往往需要编写大量的文档，而且编写完成之后还会经常改动，文档编写维护工作量大。
- 接口文档编写好后，实际的代码可能会与文档有出入，这个时候文档是不准确的，文档与代码保持修改同步也是一个很大的工作量。
- 随着接口版本的迭代，接口文档需要同步更新。
- 有些时候接口会成为对接双方的开发进度瓶颈，因为接口调用会有依赖，类似app的项目，前端会需要调用后端接口，接口功能不实现会影响前端开发进度。
- 接口开发完以后，做接口测试不方便，特别是接口数量多，参数复杂的情况，测试工作量大。
- 接口在版本迭代后，旧的接口常常需要做回归测试，这个工作量也是非常大的。
word格式在更新接口文档有很大的局限性，markdown文本在跟踪开发成员更新情况也很不方便。 - 传统维护文档的方式面临接口文档乱，格式不统一，参数填写不清晰等问题
上述分析来自 API接口管理之道
解决多人维护的问题
参考github多人维护代码思路，其采用分支的模式，各成员分工后独立开发，最后合并在一起，在实际应用中，单个接口一般是由一个程序员开发，故只需一个仓库，各成员共同维护即可。对于接口的多人维护更多的考虑是修改文档同步更新以及明确显示各成员开发进度等
而在eolinker是我看过记录最详尽的接口管理网站
-
接口文档
十分清晰的接口文档，格式统一，明确的接口分组。
接口详情里面的信息非常详细，接口的值可能性非常实用，支持富文本和markdown语法的接口详情
-
成员管理
输入队友的注册信息就可以邀请进来，分别设置了权限，比如只有管理员有导出项目文档的权限，毕竟项目的接口文档是隐私嘛，一定程度保证接口安全。
-
项目动态
开发人员了修改接口文档，操作一目了然。方便多人协作时开发人员的交流
- 接口回收站
错删误删？不存在的，接口回收站随时可以还原接口数据，手残的我，完全不担心
eolinker通过项目动态和协作管理等实现了多人维护一份文档，在我看来就是接口的github，对于个人开发者也很实用，欢迎使用后和我交流文中没发掘且利于合作的功能~
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。