由於工作的原因，經常要接觸到很多API介面，而API介面在設計時往往需要編寫大量的文件，而且編寫完成後往往需要根據實際情況，經常改動文件，這使得文件編寫維護工作量相對較大，這讓我也包括很多的開發者都很頭疼。
此外，伴隨著介面版本的迭代開發，介面文件也需要同步更新。而且介面開發完成以後，做介面測試會十分不方便，要是遇上介面數量多、引數負載的情況，那不僅不方便，測試工作量會重上加重。
我們還經常會因為交付週期的原因，需要接入一個第三方的庫，而第三方的庫通常都存在文件老舊，文件不夠全面等等或多或少的問題。那這個問題相比於沒有文件，對程式設計師來說更加難以棘手。因為會造成：我們需要的介面不在文件上，文件上的介面不存在庫裡，又或者是少了一行關鍵的程式碼。
上述的問題其實讓我在工作中很苦惱，後來經過前輩推薦一個開源而且免費的eoLinker，剛使用時的時候覺得介面很不錯，發現這個工具的開源版是基於PHP框架的，我目前使用的開源版本也能把我的資料儲存在我自己的伺服器上，保證了我的資料安全，使用了一段時間後，用起來的確還能解決一些其他問題，例如自動化測試、根據註釋生成文件之類的。感興趣的可以去了解一下，在此我分享一些使用過程中的心得。
【介面資訊清晰完善】
沒有文件的庫，就好比一個黑盒，我們無法預期它的正常行為。輸入了一個 A，預期返回的是一個 B，結果它什麼也沒有。有的時候，還丟擲了一堆異常，導致你的應用崩潰。而介面資訊模糊冗雜，不但加大了我理解的難度，還增加了無謂的溝通成本，拖延專案進度。為此，我們在編寫介面時，我一般都會考慮完善，介面錄入資訊清晰有條理，避免含糊不清的用詞和引數，後續也能檢視和修改。
【介面文件更新及時】
因為隨著介面版本的迭代開發，介面資訊有所變化，舊文件已經不能滿足介面的要求，我可以通過對相應介面文件的介面操作，根據現有介面資訊進行重新錄入，快速儲存為介面的新文件。更新及時的功能算是我最喜歡的功能了。
【介面操作歷史可溯源】
類似gitHub，介面文件的每一次改動歷史應清晰記錄下來。在後期介面管理和維護上，我只要通過對操作歷史的檢視，就可以瞭解到每次改動的目的和內容，進而更加方便管理介面。目前發現可以記錄了介面文件近十次的操作歷史，也支援介面歷史一鍵回溯功能，算是一定程度上降低了成員對介面文件誤操作的風險。
【成員許可權有所限制】
在專案開發中，由於每個團隊成員在專案中擔任的角色不同，我必須讓他們對介面文件應有不同的操作許可權，以確保相關介面文件的完整性和安全性。eolinker 提供了靈活的許可權管理，通過分配適當許可權給相應成員，保證開發時文件不被無關人員篡改。這也是我用的比較多的功能。
【介面測試同步完成】
編寫完介面文件後，為驗證介面返回值是否符合介面文件所描述的預期結果，我是需要對介面進行測試。eolinker也提供介面本地一鍵化測試功能，只要將資訊錄入eolinker介面管理平臺，就不必將介面資訊重新複製到測試工具的操作，這讓我覺得很方便。我只需要點選測試頁面，輸入測試引數值，便可完成測試。也提供mock測試功能，通過設定假資料以驗證介面的可行性。還提供自動化測試，應對不同測試場景。
這裡附上eoLinker中文網址： www.eolinker.com
以及免費開源專案的下載連結： www.eolinker.com/#/os/downlo…
github: github.com/eolinker