那些年遇到的後臺返回的奇葩json數據

前言

開發多年，遇到的後臺有不少，不一樣的人寫的代碼風格不同，寫出來的接口也不同。下面就請求失敗的接口舉個例子，讓你們看看有哪些奇葩的接口。反正我看的想打人了有木有？

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過來，叫大家本身去解碼。後臺哥們技術通常，代碼又是老項目，它也不少搞不懂，跟他溝通無效，簡直是浪費時間，沒辦法本身去處理吧。

因此 後臺java 必定要嚴格按java編程規範來作，寫出規範的接口給別人使用。他好你也好。

若是不清楚使用restful風格的接口的，能夠看看這篇文章 深刻理解什麼是RESTful 接口