一：接口規(guī)范

1.1 接口規(guī)范的重要性 接口，是APP端與服務器端交互密不可分的環(huán)節(jié)，接口的規(guī)范性會直接影響雙方對接過程中 的效率和質(zhì)量。本著快速高效開發(fā)的目的性，避免對接過程中的錯誤率。接口應當有規(guī)范的約束。 1.2 接口規(guī)范的例子： 請看下面這個例子： {"list": [{"name": "小紅","id": "100",},{"name": "小明","id": "101",}],"object":{"title":"demo",}"message": "數(shù)據(jù)加載成功","status": "SUCCESS"，"page":"1","number":"2", }

這就是一個針對于移動端，規(guī)范性接口的事例： list：只存儲list數(shù)據(jù)，為空時也返回一個空list（"list":[]）。 object:：只存儲實體類數(shù)據(jù)。 message：返回的提示消息，例如：加載成功、查詢失敗、登陸成功等。 statue：接口狀態(tài)，例如SUCCESS-成功 ERROR-失敗（靜態(tài)‘變量’大寫）。 page和number：其他可選性字段，例如頁數(shù)，list條數(shù)等等根據(jù)項目需求的字段。
規(guī)范目的： list：只能返回list數(shù)據(jù)，原因很簡單：因為如果你的一個接口返回的是list數(shù)據(jù)，那么解析的時候移動端就要創(chuàng)建一個實體類，對這個list進行【List】接收。如果你的另一個接口的list字段返回了【Object】數(shù)據(jù)，那么移動端就需要再創(chuàng)建一個實體類進行另一種格式的接收，這無疑會讓移動端不能進行代碼復用，造成代碼冗余，對性能影響增加。 建議：如果你的接口中返回的list、data這兩個是list數(shù)據(jù)，那么以后這兩個就只用來返回列表數(shù)據(jù)，obj、info這兩個返回的是實體類數(shù)據(jù)，那么以后就只返回實體類數(shù)據(jù)。message和status這兩個是必須要有的。其他字段都要確定好他們的規(guī)范。這樣就讓代碼復用性增加，錯誤率降低，查bug便捷。才能讓團隊協(xié)作開發(fā)更高效便捷。

二：接口文檔

后臺接口人員和移動端開發(fā)人員之間的配合肯定少不了接口文檔這種利器！像中大型項目可能一個接口包含的字段就有上百個，如果沒有文檔，僅僅靠兩個人口頭交流，那估計一天就能搞定幾個接口配合。 接口文檔有哪幾種形式呢？ 1.Excel、word等文檔形式。（古老的方式） 2.接口管理開源網(wǎng)站。（高效便捷）
像用Excel、word。接口開發(fā)人員進行編寫，然后發(fā)送給移動端人員。確實提高效率、但缺點也會慢慢暴露出來。優(yōu)點：方便查找、接口定型后可用。缺點：更新麻煩。在開發(fā)項目階段，這種方式是不可取的。因為在開發(fā)階段，接口的變動將會非常的大，不可能兩個程序員把接口文檔copy來copy去的。所以這個時候，接口管理開源網(wǎng)站就應景而出。 接口管理開源網(wǎng)站的優(yōu)點是開源、可以部署在自己的服務器上，比較安全。更新效率高，時時更新，方便團隊協(xié)作開發(fā)，便捷高效。而在項目結(jié)束后，還可以導出word，形成定型的接口文檔。省時省力。 在這里，接口管理工具有很多，我這里用的是eolinker。優(yōu)點的話在他的主頁已經(jīng)詳細的列了出來，這里我貼出他的主頁：點擊進入eolinker 用法的話都很簡單： 1.創(chuàng)建項目 2.邀請人員加入 3.進行編寫接口 4.進行接口測試（重要） 5.形成文檔 這里貼出使用教程：點擊進入eolinker使用教程
編寫規(guī)范： 一個完整的接口需要由以下幾部分組成 1.請求地址 例如：https://127.0.0.1:8080/xxx/xxx/xxx 2.請求方式 例如：POST、GET等 3.請求參數(shù) 例如：傳 id：“1”，name：“小明” 4.返回參數(shù) 例如：{ json... } 【參考上面的接口規(guī)范】 5.返回事例 例如：{ json... }

。。。

總結(jié)

以上是生活随笔為你收集整理的关于接口的规范和文档总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。