API介面在設計時往往需要編寫大量的文件，而且編寫完成後往往需要根據實際情況，經常改動文件，文件編寫維護工作量相對較大，有點頭疼。
由於我們專案還經常會因為交付週期的原因，需要接入一個第三方的庫，而第三方的庫通常都存在文件老舊，文件不夠全面等等或多或少的問題。那這個問題相比於沒有文件，對程式設計師來說更加難以棘手。因為會造成：我們需要的介面不在文件上，文件上的介面不存在庫裡，又或者是少了一行關鍵的程式碼。
然後我在網上找解決辦法，找到了eoLinker，作為苦逼的開發，在此分享我一些使用過程中的心得，希望都能脫（ji）離（xu）苦（kai）海（fa）。
介面資訊清晰了
沒有文件的庫，就好比一個黑盒，我們無法預期它的正常行為。輸入了一個 A，預期返回的是一個 B，結果它什麼也沒有。有的時候，還丟擲了一堆異常，導致你的應用崩潰。
而介面資訊模糊冗雜，不但加大了開發人員理解的難度，還增加了無謂的溝通成本，拖延專案進度。
為此，我們在編寫介面時，應考慮完善，介面錄入資訊清晰有條理，避免含糊不清的用詞和引數。
介面更新及時
隨著介面版本的迭代開發，介面資訊有所變化，舊文件已經不能滿足介面的要求，開發者可以通過對相應介面文件的介面操作，根據現有介面資訊進行重新錄入，快速儲存為介面的新文件。
介面操作歷史可溯源
類似gitHub，介面文件的每一次改動歷史應清晰記錄下來。在後期介面管理和維護上，通過對操作歷史的檢視，開發者可以瞭解到每次改動的目的和內容，進而科學管理介面。
eolinker AMS記錄了介面文件近十次的操作歷史，支援介面歷史一鍵回溯功能，降低了成員對介面文件誤操作的風險。
成員許可權有所限制
在專案開發中，由於每個團隊成員在專案中擔任的角色不同，他們對介面文件應有不同的操作許可權，以確保相關介面文件的完整性和安全性。
eolinker AMS提供了靈活的許可權管理，通過分配適當許可權給相應成員，保證開發時文件不被無關人員篡改。
介面測試同步完成
編寫完介面文件後，為驗證介面返回值是否符合介面文件所描述的預期結果，開發者們需要對介面進行測試。
eolinker AMS提供介面本地一鍵化測試功能，只要將資訊錄入eolinker介面管理平臺，你將會省去將介面資訊重新複製到測試工具的操作。你只需要點選測試頁面，輸入測試引數值，便可完成測試。
還提供mock測試功能，通過設定假資料以驗證介面的可行性。
以上！