前言
開發(fā)多年，遇到的后臺有很多，不同的人寫的代碼風格不一樣，寫出來的接口也不一樣。下面就請求失敗的接口舉個例子，讓大家看看有哪些奇葩的接口。反正我看的想打人了有木有？
1. 返回一片空白。
大哥，你這是要干啥呢。。。沒有錯誤信息，我怎么知道請求成功還是失敗。。這是在挑戰(zhàn)我的智商嗎？
（建議：下次遇到這樣的，直接揍一頓，就說是我說的。下面這張圖送給你們后臺吧。)
2.key是數(shù)字，value也是數(shù)字，你當我是小學(xué)生呢？
如下所示：
{
1:"123",
2:"456",
3:"789"
}
3.返回空字符串，大哥，你這是鬧啥子。。
{
"result":""
}
4.這個還看得過去，至少有個json數(shù)據(jù)返回。
然而：你給我返回的null什么意思。。。還不如不返回。。。這樣設(shè)計有啥意義。。
{
"data":"null"
}
5.比上面那個更可惡，有錯誤數(shù)據(jù)返回，有錯誤信息描述。
然而：錯誤數(shù)據(jù)返回null不說，錯誤信息居然返回一個一個url？就這么一點錯誤信息，還要我再去請求一次服務(wù)器獲取這個錯誤信息嗎。。
服務(wù)器流量不要錢的吧。。。經(jīng)得起這樣折騰？后臺哥們啊，走點心吧！為老板省點流量錢吧，同時也要提高用戶體驗??！用戶請求網(wǎng)絡(luò)的流量也不能由你這樣去折騰。。
{
"data":"null",
"desc":"/error/desc"
}
6. 返回url就算了，為什么加一個/轉(zhuǎn)義字符？
{
"error":"http://error_desc"
}
7. 返回url就算了，居然還有返回中文的，用的是unicode轉(zhuǎn)換的？我用的時候要把它轉(zhuǎn)換回來。。很麻煩。。
{
"error":"/%2F%E9%94%99%E8%AF%AF%E4%BF%A1%E6%81%AF"
}
8. 返回的圖片不是url,而是base64編碼，我還要去用base64編碼去處理。你是在逗我嗎？讓我看天文數(shù)字，給個url很難嗎？
9. 還有的是全部是拼音的
{
"cuowuma": 1,
"cuowuxinxi":"請求失敗"
}
10. 返回拼音也就算了，還有返回拼音縮寫的
拼音縮寫誰看得懂這是干啥用的？猜字謎嗎？？？
11. 返回的json里面某些字段是java的關(guān)鍵字
問題：json里面某些字段是java的關(guān)鍵字，轉(zhuǎn)成實體類的時候，會報錯。
{
"abstract": "Success",
"id": "503",
"package": "50"
}
轉(zhuǎn)成實體類如下，會報錯：
public class ResultEntity {
private String abstract;
private String id;
private String package;
//...get set方法省略
}
- 對老司機來說，這種小問題當然也是有解決辦法的。使用google提供的序列化工具，按下面這樣寫，就可以正常的將數(shù)據(jù)反射到字段中了。
public class ResultEntity {
@SerializedName("abstract")
private String successInfo;
private String id;
@SerializedName("package")
private String packageNumber;
//...get set方法省略
}
- tips：按java編程規(guī)范來說，接口中是不能包含java關(guān)鍵字的。所以 奉勸各位
后臺新手不要心存僥幸心理，一切都要按規(guī)范來做，這樣對你今后的開發(fā)會有很多幫助。
12. 返回的相同字段用的不同的數(shù)據(jù)類型，這個是最苦逼的，解析都不好處理。
比如下面這個，id字段，前面的是數(shù)字類型（我們這邊暫定為int類型），最后一個是String類型，后臺說是GUID，不管它是什么鬼，看到這種只想打人。萬一哪天服務(wù)器把id都改成int類型了，客戶端這邊的代碼中涉及到這個id字段的所有地方都要跟著改動，這不是坑爹嗎。。。
[
{
"id": "503",
"name": "License",
"picture": "/userfiles/upload/2017/503.png"
},
{
"id": "504",
"name": "其它",
"picture": "/userfiles/upload/2017/504.png"
},
{
"id": "80896a88d8c3449bb90c4781ddbd4d49",
"name": "TH inkaNet",
"picture": "/userfiles/upload/2017/81211f2db0c649318e7166e447e91186.jpg"
}
]
13. 多層嵌套的json，在中間的某一層后臺返回的是null，這種情況解析起來很麻煩的。
舉例說明：
{
"data": [
{
"id": "101",
"info": [
{
"name": "張1",
"code": "10101"
},
{
"name": "張2",
"code": "10102"
},
{
"name": "張3",
"code": "10103"
}
]
},
{
"id": "102",
"info": [
{
"name": "張4",
"code": "10201"
},
{
"name": "張5",
"code": "10202"
},
{
"name": "張6",
"code": null
}
]
},
{
"id": "104",
"info":null
}
]
}
正確做法： 不管有沒有數(shù)據(jù)返回，都要寫清楚返回字段。
14. 有數(shù)據(jù)的時候返回的類型不統(tǒng)一，有數(shù)據(jù)的時候返回的是json array類型，沒有數(shù)據(jù)返回的時候成了json object類型。
比如我遇到過的后臺返回的數(shù)據(jù)舉例如下：
有數(shù)據(jù)返回的時候：
{
"id": "102",
"info": [
{
"name": "張4",
"code": "10201"
},
{
"name": "張5",
"code": "10202"
},
{
"name": "張6",
"code": null
}
]
}
沒有數(shù)據(jù)返回的時候,info這個json array類型怎么就變成了json object類型？莫名其妙：
{
"id": "102",
"info": {
"name": "",
"code": ""
}
}
以下是正確做法，請廣大
后臺新手get一下：
正確做法： 字段結(jié)構(gòu)不能隨意修改，不管有沒有數(shù)據(jù)返回都不要隨意修改，沒有數(shù)據(jù)的就搞一些默認空值填上去。
15. 有時候遇到后臺是新手，那就苦逼了，直接給你返回雙引號里面包裹著json字符串，同時夾雜著\轉(zhuǎn)義字符。
后臺哥們說，你們客戶端的自己去拆分解析吧。我看的想打人，你封裝成一個對象，用[]返回不行嗎？建議：看到這樣的json，遇到后臺哥們見一次打一次。只想甩他一張圖。
請看下圖。這是json格式化之后看到的效果，關(guān)鍵字涉及隱私，已打碼處理。
下面來一個正確的示范：
這是一個很規(guī)范的接口設(shè)計，看著很舒服，處理起來很方便。（順便說一句，推薦大家使用restful風格的接口）
{
"errorCode": 1,
"errorMsg": "請求失敗",
"data": {
"message": "Problems parsing JSON"
}
}
后記：
奉勸各位java新手 或者 混了幾年的老油條，如果你寫出的接口是以上這些，或者還有其他的奇葩接口，請好好的反思一下，不要有僥幸心理，認為獨立開發(fā)或者小公司無所謂，有這種想法的人勸你先去面壁三分鐘。
這里我總結(jié)一下規(guī)范的接口的意義所在。
- 1.它是個人基礎(chǔ)業(yè)務(wù)能力的一個展現(xiàn)。
同樣3年java開發(fā)兩個人，一個寫的接口條理清晰，結(jié)構(gòu)明確，一目了然；另外一個人寫出了類似上面這類的接口。
很明顯，前者給人的感覺是基礎(chǔ)是比較扎實的。我個人理解，接口編寫對于做后臺的來說是家常便飯，它算是一門
基本功，就好比練武之人扎馬步一個道理。后臺跟前端或者客戶端交互都要靠接口，接口寫不好，還談什么交互？
所以，能寫出好的接口的人，至少有一點可以看出來，基礎(chǔ)是比較扎實的。
- 2.它是代碼規(guī)范素養(yǎng)的一種體現(xiàn)。
接口寫的好的人，可以推斷這個人寫代碼應(yīng)該也是比較規(guī)范的（雖然不能百分之百肯定，但至少它規(guī)范的要求自己寫接口）。
假如有一天，你能去大公司，你要是寫的很差的接口，我敢保證，你也在那里呆不長就被辭退，除非是不注重技術(shù)的所謂的大公司。
- 3.為后續(xù)接口維護節(jié)省了很多時間。
接口寫不好的，后續(xù)加功能或者改接口，那就等著加班加點苦逼的去修改吧。同時也耽誤了前端或者客戶端的開發(fā)進度。
- 4.規(guī)范的接口可以減少前后端人員為了一個字段在哪一端處理引發(fā)的不必要的爭吵。
之前我就遇到過明明后臺可以處理的比如base64編碼，明明可以傳一個url給客戶端的，非要搞一個base64過來，叫你們自己去解碼。后臺哥們技術(shù)一般，代碼又是老項目，它也很多搞不懂，跟他溝通無效，簡直是浪費時間，沒辦法自己去處理吧。
