我的开源经历：为了方便处理三方 HTTP 接口而写的 Java 框架

缘起

我以前公司需要在 Java 后台调用许多第三方 HTTP 接口，比如微信支付、友盟等等第三方平台。 公司内部还有很多服务是用世界最好语言写的，接口自然也只能通过 HTTP 接口来调用。于是日积月累下来，在 Java 代码中就有许许多多各式各样的 HTTP 调用接口，而且调用方式也不统一，有 HttpClient 写的、有 OkHttp 写的、有自己包装的，光公司内部不同人包装的 HTTP 工具类就有两三种。 而且 url 基本写死在代码中，很难维护，不同接口又有不同的参数传输方式，有 GET 、有 POST，有 JSON 传输的、有 XML 传输的。 当有一个接口需要修改，完了，光找到代码在什么地方就要花半天时间。

起步

于是，我就想能不能将所有 Java 的 HTTP 接口封装成风格统一的接口，使得 http 信息和业务代码解耦，让接口调用方压根就需要要关系 HTTP 请求发送的细节，关注接口本身要做什么事即可。就像 Dubbo 那种 RPC 接口一样，对请求调用方来说只是调用一个普通的 Java 接口对象的普通 Java 方法，传入需要 Java 基本类型或对象作为参数值，返回一个 Java 对象作为返回值，整个过程感受不到 HTTP 的存在。 所有 HTTP 相关的信息都通过注解标注在接口和方法上，如同 JPA 那样，当要维护 HTTP 接口的时候一目了然。

然后，我于 2015 年开始编写Forest，在那个时候不知有 Feign，无论 Retrofit (^▽^ )。所谓无知者无畏，没多久就完成了第一版本，并在公司内部顺利推广开来，尽管早起版本有各种各样 Bug，但大家反应还是一个字：香。

Gitee 地址：https://gitee.com/dt_flys/forest

挑战

这也直接促使我在 2016 年将其开源，在 Gitee 上三天内涨到了 100 star，但当时我并不懂得如何推广和维护一个开源社区，所以 star 数的增长也就后继无力了。

而且渐渐得知有 Feign 和 Retrofit 的存在，对我也是个不小打击，毕竟人家已经十分成熟了，我也就放弃了 Forest 一段时间。

转机

不过，在这段时间已经在公司的生产环境使用 Forest，在同事的反馈下不断地做些修修补补（毕竟我写的，就要负责到底），但也正因为如此 Forest 渐渐成熟和稳定下来。同时，在同事的鼓励下，我也想到了 Forest 属于自己的发展路线：替换 HttpClient 和 OkHttp，与 Retrofit 和 Feign 做差异化，相比 Retrofit 与 SpringBoot 集成更好，与 Feign 相比更针对于第三方 HTTP 接口，同时有完善的中文文档、中文社区，方便国内开发者解决问题。

现状

至此，我于今年下半年重新拾起 Forest，不断迭代，自今年 7 月份以来得到了 500+ star，虽然与上千 star 的知名项目来比算不了什么，但对我也是极大的鼓励，也让我慢慢理解应该如何去做好一个开源项目。

心得

经过Forest这样一个开源项目，以及结合我自己的感受，要做好开源至少要做到以下几点：

1、能解决痛点：必须是日常实际工作中会碰到的痛点，这种痛点其实有很多，但通常因为平时痛的太久了而不易察觉，仔细找还是能找到的。

2、详尽的文档：开源项目也是一种产品，只有提供了详尽易懂的文档，别人才知道怎么使用你提供的工具或框架。

3、反馈的渠道：微信群或QQ群都行，在接受到了使用者的反馈之后，很快就能知道下步该如何迭代，未来改进的方向是什么。同时也提供了一个可供大家交流学习的场所。

4、适当的宣传：没有宣传就没有人用，这是很现实的问题。除了少数天选之子能自带流量外，绝大部分项目都要靠你主动推销自己才能获得用户，而有了用户你的项目才有意义。这就像“天下不会掉馅饼”这样简单的道理朴实无华，但要真正实现起来也绝非易事。

5、长期的维护：这才是最重要、也是最难的一点：坚持。开源并不是把项目做到放到Github或Gitee，写两篇软文就完事了，这只是万里长征第一步。开源项目也是种产品，也符合软件工程的原理。它需要开发者长期的、连续不断的投入以保持它持续不断的迭代更新，它才有那么一丝可能来展现出它自己的生命力。

哈哈~ 我要说的就这么多，以上只是我这些年来浅薄的感悟，希望能帮助到有心投入到开源、或者对开源感兴趣的小伙伴们。