多人維護一份文檔必須知道的管理網站-接口的github

傳統維護文檔方式
1.word格式文檔
2.在線markdown文本前端

API管理的痛點
  • API接口在設計時每每須要編寫大量的文檔,並且編寫完成以後還會常常改動,文檔編寫維護工做量大。
  • 接口文檔編寫好後,實際的代碼可能會與文檔有出入,這個時候文檔是不許確的,文檔與代碼保持修改同步也是一個很大的工做量。
  • 隨着接口版本的迭代,接口文檔須要同步更新。
  • 有些時候接口會成爲對接雙方的開發進度瓶頸,由於接口調用會有依賴,相似app的項目,前端會須要調用後端接口,接口功能不實現會影響前端開發進度。
  • 接口開發完之後,作接口測試不方便,特別是接口數量多,參數複雜的狀況,測試工做量大。
  • 接口在版本迭代後,舊的接口經常須要作迴歸測試,這個工做量也是很是大的。
    word格式在更新接口文檔有很大的侷限性,markdown文本在跟蹤開發成員更新狀況也很不方便。
  • 傳統維護文檔的方式面臨接口文檔亂,格式不統一,參數填寫不清晰等問題

上述分析來自 API接口管理之道git

解決多人維護的問題

參考github多人維護代碼思路,其採用分支的模式,各成員分工後獨立開發,最後合併在一塊兒,在實際應用中,單個接口通常是由一個程序員開發,故只需一個倉庫,各成員共同維護便可。對於接口的多人維護更多的考慮是修改文檔同步更新以及明確顯示各成員開發進度等
而在eolinker是我看過記錄最詳盡的接口管理網站程序員

eolinkergithub

  • 接口文檔
    接口文檔

十分清晰的接口文檔,格式統一,明確的接口分組。後端

接口詳情頁
接口詳情裏面的信息很是詳細,接口的值可能性很是實用,支持富文本和markdown語法的接口詳情安全

  • 成員管理
    成員管理

輸入隊友的註冊信息就能夠邀請進來,分別設置了權限,好比只有管理員有導出項目文檔的權限,畢竟項目的接口文檔是隱私嘛,必定程度保證接口安全。markdown

  • 項目動態
    項目動態

開發人員了修改接口文檔,操做一目瞭然。方便多人協做時開發人員的交流app

  • 接口回收站

接口回收站
錯刪誤刪?不存在的,接口回收站隨時能夠還原接口數據,手殘的我,徹底不擔憂測試

eolinker經過項目動態和協做管理等實現了多人維護一份文檔,在我看來就是接口的github,對於我的開發者也很實用,歡迎使用後和我交流文中沒發掘且利於合做的功能~網站

相關文章
相關標籤/搜索