今天與另一位前端開發(fā)人員扯起了后端接口的皮（我也是前端人員），那個(gè)兄弟對(duì)后端人員提供的接口很大的意見（我是司空見慣），不過他說的也確實(shí)有道理，所以結(jié)合我的見解，希望提供接口的人員能多加注意。

1.沒有文檔...

例如新的前端人員到了一個(gè)新的公司，使用接口時(shí)，問這個(gè)這個(gè)不知道，問那個(gè)那個(gè)不知道，要文檔沒文檔，這絕對(duì)是前端人員最抓狂的事，心里肯定是一千只草泥馬奔騰而過。

為什么要文檔？

1. 文檔是當(dāng)前開發(fā)者甚至后面的接盤俠（后面開發(fā)者）能夠清晰往下做的指引。

2.?即便是簡(jiǎn)單的東西，但如果不寫文檔，以后口口相傳消耗的工作量會(huì)比寫文檔更多。

3. 好記性不如爛筆頭，一段時(shí)候后，可能連開發(fā)者都忘記接口的用途。

文檔怎么寫？

1. 在線文檔。

在線文檔易于更新和他人查看，例如可以使用Swagger編寫接口文檔。

PS：Swagger是一個(gè)規(guī)范和完整的框架，用于生成、描述、調(diào)用和可視化RESTful風(fēng)格的Web服務(wù)。

2. 本地文檔。

本地文檔一般用Word文檔，但是比較不易傳播，但能離線查看。

Final~

文檔是及其關(guān)鍵的，無論是在線文檔還是本地文檔，有是關(guān)鍵。雖然寫文檔是麻煩的事，但對(duì)后端人員來說，是利人利己。

2.文檔不全...

額，就是有了文檔，文檔里面對(duì)接口的描述也可能不全，可能缺每個(gè)參數(shù)詳盡描述（取值范圍、類型）、請(qǐng)求方式（GET、POST、PUT、DELETE）、返回?cái)?shù)據(jù)的所有狀態(tài)等等。這里面可能最缺就是返回?cái)?shù)據(jù)的狀態(tài)！

一般的返回?cái)?shù)據(jù)結(jié)構(gòu)~

公司的數(shù)據(jù)接口返回結(jié)構(gòu)是

{s : 0/ 1, //表示此操作的處理狀態(tài)（ status ），一般簡(jiǎn)單的成功 /不成功，使用 1/0 表示。m : 'xxxx', //表示此操作的提示信息（ message ），一般只用來顯示操作失敗時(shí)提示信息。r : [], //表示此操作的返回值（ result ）count : x //返回的數(shù)據(jù)條數(shù) }

這種數(shù)據(jù)結(jié)構(gòu)看起來沒問題，確實(shí)也沒大問題，問題就是出在s這個(gè)字段。有許多的接口不僅僅只有兩種狀態(tài)，成功狀態(tài)只有一種倒是沒問題，問題就出在失敗狀態(tài)，失敗可能有很多情況，一個(gè)簡(jiǎn)單的s:0不能說明失敗的原因（即便是有m提示信息，但用這個(gè)來區(qū)分很不靠譜，因?yàn)樘崾究赡軙?huì)變化），我們不總是僅拿m做顯示用。

升級(jí)返回?cái)?shù)據(jù)結(jié)構(gòu)~

那位同事建議以下方式應(yīng)答

{s : 0/ 1/ 2/ 3, // 0代表正常，1是參數(shù)有誤，2是用戶不存在，3是用戶沒權(quán)限等等m : 'xxxx', //表示此操作的提示信息（ message ），一般只用來顯示操作失敗時(shí)提示信息。r : [], //表示此操作的返回值（ result ）count : x //返回的數(shù)據(jù)條數(shù) }

m、r、count?可以保持不變，但是s里面必須包含所有返回狀態(tài)，代表這個(gè)接口所有業(yè)務(wù)的情況，前端開發(fā)人員也就能針對(duì)每種情況進(jìn)行處理。

Final~

文檔最重要的部分是返回值的狀態(tài)，我也建議上面的升級(jí)返回?cái)?shù)據(jù)結(jié)構(gòu)，這樣就不存在任何不明朗情況。既然寫了文檔，就把文檔寫好，寫明朗，這也是利人利己地方。

3.接口參數(shù)沒校驗(yàn)...

這個(gè)前端人員倒不是很關(guān)注，因?yàn)楸旧碚{(diào)接口之前都會(huì)先做校驗(yàn)，后端做參數(shù)校驗(yàn)只是雙重保證。我之前也做過一段時(shí)間后端，也犯過沒校驗(yàn)參數(shù)的錯(cuò)，額，因?yàn)楹髞頉]有做后端，也就沒有去修正。不過還是提醒后端人員，做好參數(shù)校驗(yàn)是第一步，不要偷懶了。

Final~

統(tǒng)一處理好接口校驗(yàn)，后端好好考慮下。

4.沒保證接口原子性...

接口的原子性很重要，有時(shí)一個(gè)接口可能會(huì)干幾件事，但不一定都能正常完成，這就導(dǎo)致可能存在原子性問題，接口不能準(zhǔn)確被調(diào)用。

PS：原子性。一個(gè)原子事務(wù)要么完整執(zhí)行，要么干脆不執(zhí)行。這意味著，工作單元中的每項(xiàng)任務(wù)都必須正確執(zhí)行。如果有任一任務(wù)執(zhí)行失敗，則整個(gè)工作單元或事務(wù)就會(huì)被終止。即此前對(duì)數(shù)據(jù)所作的任何修改都將被撤銷。如果所有任務(wù)都被成功執(zhí)行，事務(wù)就會(huì)被提交，即對(duì)數(shù)據(jù)所作的修改將會(huì)是永久性的。

Final~

原子性一定要保證，保證，保證！

5.接口問題不斷...

前端開發(fā)人員調(diào)接口時(shí)候，可能會(huì)存在各自各樣的問題，有問題可以理解，程序哪會(huì)沒有bug，但不能太離譜啊，后端兄弟們。所以我覺得在給出接口之前自己明確幾件事：

1. 是否校驗(yàn)參數(shù)。

2. 是否所有的情況都測(cè)試過了，如果可以請(qǐng)寫單元測(cè)試。

3. 是否返回?cái)?shù)據(jù)準(zhǔn)確明朗，響應(yīng)狀態(tài)碼是否正常。

4. 文檔是否已經(jīng)完備。

?

總結(jié)

后端人員多體諒前端人員，在出現(xiàn)問題時(shí)，先檢查自身，別一上來就跟前端干起來，要是自己的問題就尷尬了。

本文為原創(chuàng)文章，轉(zhuǎn)載請(qǐng)保留原出處，方便溯源，如有錯(cuò)誤地方，謝謝指正。

轉(zhuǎn)載自https://www.cnblogs.com/lovesong/archive/2016/05/26/5533149.html

總結(jié)

以上是生活随笔為你收集整理的前端后端接口那些事吐槽的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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