我們為什麼需要API管理系統？
摘要：
隨著web技術的發展，前後端分離成為越來越多網際網路公司構建應用的方式。前後端分離的優勢是一套Api可被多個客戶端複用，分工和協作被細化，大大提高了編碼效率，但同時也帶來一些“副作用”:
介面文件不可靠。很多小夥伴管理介面文件，有使用wiki的，有word文件的，甚至還有用聊天軟...
隨著web技術的發展，前後端分離成為越來越多網際網路公司構建應用的方式。前後端分離的優勢是一套Api可被多個客戶端複用，分工和協作被細化，大大提高了編碼效率，但同時也帶來一些“副作用”:
- 介面文件不可靠。很多小夥伴管理介面文件，有使用wiki的，有word文件的，甚至還有用聊天軟體口口相傳的，後端介面對於前端就像一個黑盒子，經常遇到問題是介面因未知原因增加引數了，引數名變了，引數被刪除了。
- 測試資料生成方案沒有統一出口。我們都有這樣的經歷，前端開發功能依賴後端，解決方案有自己在程式碼注入json的，還有後端工程師臨時搭建一套測試資料伺服器，這種情況下勢必會影響工作效率和程式碼質量，也不能及時進行更新。
- 資源分散，無法共享。介面除錯每個開發者單獨維護一套Postman介面集，每個人無法共用其他人的介面集，存在大量重複填寫請求引數工作，最重要的是postman沒法跟介面定義關聯起來，導致後端沒有動力去維護介面文件。
除了以上三點，對於我們公司的開發流程又會出現以下問題：
- 由於咱們公司的開發形式為多工並行，前端與後端齊頭並進各自開發，雖然原型只有一份，但是每個人的理解可能不止一種，這就導致當前後端都完成各自的前置後進行介面對接時出現欄位不一致，多欄位或少欄位等問題，然後其中一方甚至雙方對之前產出的程式碼進行更改，這裡就會浪費大量的時間。
- 現在咱們專案的介面文件主要依靠word進行編寫,一旦接口出了問題，更改文件的過程會十分繁瑣耗時。
除了以上問題之外，我們可能還會遇到一些其他問題，比如文件的匯出，模組的劃分，操作的便捷性等等。帶著這些問題我對國內外的一些介面管理系統做了簡單的調查，推薦度較高的有一下幾個：