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