一、示例：
1.1：通過登錄界面登錄百度流程：
如上圖：我們在界面的登陸框輸入正確的用戶名和密碼，點擊登錄，登錄成功。
1.2：程序內部流程：
（1）前端發送請求到服務端，
（2）服務端收到請求去數據庫查數據，發現有這個帳號，密碼也正確
（3）服務端返回給前端登錄成功，以及該帳號下的數據
（4）前端解析數據，進入登錄成功界面，展現該帳戶的內容
1.3：開發過程可能出現的問題：
如若上描述，服務端收到前端請求的時候，要解析出用戶名和密碼。
那麼問題來了：
如上圖，前端美眉認爲：用戶名這個參數要用user指代，密碼這個參數要用pwd指代。
如上圖，RD小哥哥認爲：用戶名這個參數要用username指代，密碼這個參數要用password指代。
然後：前端傳請求帶參數user=桃夭queen、pwd=Ilovetest；後端收到請求要提取username和password這兩個參數的值，發現沒有這兩個字段，直接返回錯誤。
再然後：RD小哥哥跑去找前端美眉，你沒給我傳參數。然後balabala。。。。
最終：兩個人確定參數名稱，按規則進行參數傳遞。OMG，接口終於可以跑通了。
這還只是一個參數，實際上每個接口都會有很多參數。這就會出現前端美眉和RD小哥哥不停的跑來跑去進行交流。而且他們兩個人定義好了，其它同學在調用這個接口的時候理解又不一致，我們測試的時候也要找不同的RD去問各種參數情況，這溝通成本太太太高了。
綜上所述：要有一個統一的接口文檔，來指定參數名稱、參數類型、參數取值範圍、參數含義等等。
二、接口文檔的作用：
1、項目開發過程中：前後端RD要有一個統一的文檔進行溝通交流
2、項目維護中：可以隨時查看、維護。
舉例詳解：
項目上線了，我新增了一個功能，要調用這個接口或修改這個接口，這個時候就可以查看接口文檔明確接口情況。
3、項目人員變更：方便後期人員查看、維護。
舉例詳解：
（1）項目A是桃夭queen負責測試的，一個星期後這一期測試完成，桃夭queen被調去負責其它項目了。調來了豬豬同學負責這個項目，接口功能變更需要測試。豬豬的心理：“天啊，文檔也沒有，記錄也沒有，啥也沒有，啥也不知道，我在哪裏，我在幹嘛”。要重新找RD明確接口情況，時間和溝通成本超高。
（2）RD小熊負責開發項目A，一年後離職啦。RD小馬入職負責這個項目。新增需求，開發的過程中小馬“這塊也沒有文檔，看代碼這個接口沒有地方調用，冗餘了，我優化下，把它幹掉吧。”小馬勤奮一下然後悲劇啦。。。。程序功能不可用啦。這風險超級大啊。
4、作爲接口測試的依據。
舉例詳解：
沒有接口文檔，不知道怎麼拼接URL，不知道怎麼確定參數，沒有辦法進行測試。
三、接口文檔組成
1、接口說明：接口乾嘛的，要是先什麼功能
2、接口url：發請求、拼參數要用
3、請求方法：get/post
4、請求參數：參數名稱、類型、長度、是否必填、參數說明等
5、返回值：格式，參數名稱、類型、長度、是否爲空、參數說明等
6、錯誤碼：針對不同的錯誤情況，要有對應的錯誤碼和提示文案。
四、接口文檔舉例
接口地址：http://v.juhe.cn/toutiao/index
返回格式：json
請求方式：get/post均可
請求示例：http://v.juhe.cn/toutiao/index?type=top&key=APPKEY
接口備註：返回頭條，社會，國內，娛樂，體育，軍事，科技，財經，時尚等新聞信息
請求參數說明：
返回參數說明：
錯誤碼：
