緣起
我以前公司需要在 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，寫兩篇軟文就完事了，這只是萬里長征第一步。開源專案也是種產品，也符合軟體工程的原理。它需要開發者長期的、連續不斷的投入以保持它持續不斷的迭代更新，它才有那麼一絲可能來展現出它自己的生命力。
哈哈~ 我要說的就這麼多，以上只是我這些年來淺薄的感悟，希望能幫助到有心投入到開源、或者對開源感興趣的小夥伴們。