json知識講解
json的定義
json(javascript object notation, js 對象簡譜) 是一種輕量級的數據交換格式。它基于 ecmascript (歐洲計算機協會制定的js規范)的一個子集，采用完全獨立于編程語言的文本格式來存儲和表示數據。簡潔和清晰的層次結構使得 json 成為理想的數據交換語言。 易于人閱讀和編寫，同時也易于機器解析和生成，并有效地提升網絡傳輸效率。
解釋來自于百度百科，說簡單點。json就是一串字符串 只不過元素會使用特定的符號標注。
json的幾種常見格式
對象
|
1
2
3
4
|
{"username": "清風一陣吹我心","password": "123456"} |
數組
|
1
2
3
4
5
|
["one","two","three"] |
對象數組
|
1
2
3
4
5
6
7
8
9
10
11
12
|
{"student": ["張三","李四","王五"],"teacher": ["語文","數學","英語"]} |
數組對象
|
1
2
3
4
5
6
7
8
9
10
|
[{"username": "張三","age": 18},{"username": "李四","age": 20}] |
復雜的格式
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
{ "msg": "查詢成功", "code": 200, "data": { "provinces": [ { "name": "重慶", "cities": [ { "name": "重慶市", "district": [ "江北區", "渝北區", "萬州區", "合川區" ] } ] }, { "name": "北京", "cities": [ { "name": "北京市", "district": [ "海淀區", "昌平區", "朝陽區", "豐臺區" ] } ] } ] }} |
使用json的好處
- 與xml相比，數據格式比較簡單, 易于讀寫
- 格式都是壓縮的, 占用帶寬小
- 便于服務器端的解析，支持多種語言。包括c，c#，java，javascript， perl，php，python，ruby等。
json的知識，就講到這里。
最近在弄監控主機項目，對javaweb又再努力學習。實際的項目場景中，前后分離幾乎是所以項目的標配，全棧的時代的逐漸遠去，后端負責業務邏輯處理，前端負責數據展示成了一種固定的開發模式。像thymeleaf這種東西沒法實現前后端分離模板難學也只有寫java的才用吧，還是用js模板引擎接受json好。
1. json報文
springboot 默認會使用 json 作為響應報文格式。首先，我們創建一個 usercontroller 用于處理前端的 web 請求。
定義一個簡單的控制器，與通常返回 url 的 controller 不一樣的是，login() 使用了 @responsebody 注解，它表示此接口響應為純數據，不帶任何界面展示，可以獲得標準json。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
@controller@requestmapping("/user")public class usercontroller { @requestmapping("/login") @responsebody public respentity login(@requestbody requser requser) { //使用requser模型來接受，而不用user user user = new user(); if(requser != null) { user.setname(requser.getname()); user.setpassword(requser.getpassword()); } return new respentity(respcode.success, user); //返回的響應實體具體看下節 }} |
對于上面的代碼來說，還可以做進一步的優化，由于所有的 restful 接口都只是返回數據，所以我們可以直接在類級別上添加 @responsebody 注解。而大多數情況下，@controller 與 @responsebody 又會一起使用，所以我們使用 @restcontroller 注解來替換掉它們，從而更加簡潔地實現功能。
2. 接口規范
對于每一家公司來說，都會定義自己的數據規范，一個統一且標準的數據規范對于系統維護來說是非常重要的，也在很在程度上提升了開發效率。
2.1 響應報文規范
接口響應至少需要告訴使用方三項信息：狀態碼、描述、數據。其中，數據不是每個接口必須的，如果只是一個簡單修改的動作，可能就沒有必須返回數據了。下面我們定義一個 respentity類來封裝我們的響應報文model:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
public class respentity { private int code; private string msg; private object data; public respentity(respcode respcode) { this.code = respcode.getcode(); this.msg = respcode.getmsg(); } public respentity(respcode respcode, object data) { this(respcode); this.data = data; } ... } |
同時，定義一個枚舉類來維護我們的狀態碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
public enum respcode { success(0, "請求成功"), warn(-1, "網絡異常，請稍后重試"); private int code; private string msg; respcode(int code, string msg) { this.msg = msg; } public int getcode() { return code; } public string getmsg() { return msg; }} |
這樣，我們的響應數據規范已基本建立。
2.2 請求數據規范
響應報文格式我們已經定義好了，那么請求數據我們如何接收呢？
一般來說，請求與響應會使用相同的報文形式。如果響應為json，那么請求也建議使用json。
為登錄請求添加輸入參數，首先，需要我們定義好用戶實體user類，直接在映射方法login() 使用該實體進行參數接收，并將接收到的參數直接返回，1.節代碼已實現。
調出postman，填寫正確的url，選擇post方式發送請求，選擇body，將 content-type 設置成 application/json，填入 json 格式的請求數據，點擊 send 即可得到如下結果。
數據接收非常成功，但在上面的響應報文中，存在著了一個非常嚴重的問題，那就是用戶的密碼也隨同用戶信息一起返回給了客戶端，顯然這并不是一種正確的做法。
我們需要對其進行一次過濾，由于 springboot 默認使用 jackson 作為 json 序列化工具，如果想要過濾掉響應中的某些字段，只需在過濾字段對應的 get 方法上加上 @jsonignore 注解即可。
但這樣又會引發另外一個問題，那就是請求中的字段也被過濾掉了，對于這種問題，可以采用抽離請求參數模型的方式進行處理，即自定義一套參數接收的 model，比如，接收用戶登錄的會使用 requser 來進行參數接收，這樣使得請求參數模型與數據庫映射實體完全分離，在一定程度上提升了系統的安全性。替換成 model 對象后（1.節的代碼已經替換好了），我們就可以在數據庫映射實體 user 上增加 @jsonignore 注解忽略該字段的序列化，而不影響請求參數的輸入。
3. 參數校驗
出于系統健壯性的考慮，我們需要對所有的參數進行必要性校驗，如：登錄請求時，如果沒有用戶名，程序應該立即駁回該請求。上面請求參數模型（model）的抽象也使得我們對數據校驗更加方便，當然主要還是依賴于 springboot 的 validate 功能的強大支持。
3.1. 簡單參數校驗
對于登錄接口來說，用戶名與密碼都是必輸的，那么我們現在為其添加上對應的參數校驗，無需 if-else 判斷，簡單的幾個注解就可以幫助我們完成所有的工作。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public class logincontroller { @requestmapping("/login") @responsebody public respentity login(@requestbody @valid requser requser) { }}----public class requser { @notblank(message = "用戶名不能為空") public string getname() { return name; } @notblank(message = "密碼不能為空") public string getpassword() { return password; } ...} |
我們為請求參數的 model 對象requser 加上了 @valid 注解，并在 model 類中對需要校驗字段的 get 方法上添加相應的校驗注解。效果如下：
3.2. 復雜參數校驗
正則表達式校驗
如果用戶的登錄名為手機號，那么就需要對登錄名的格式做進一步的校驗，下面使用正則表達式來校驗手機號的合法性。
|
1
2
3
4
5
6
7
8
|
@notblank(message = "用戶名不能為空")@pattern( regexp = "1(([38]\\d)|(5[^4&&\\d])|(4[579])|(7[0135678]))\\d{8}", message = "手機號格式不合法")public string getusername() { return username;} |
自定義校驗注解
在系統使用過程中，有很多地方需要對手機號的格式進行校驗，如：注冊、驗證碼發送等。
但校驗手機號的正則表達式又過于復雜，如果多處編寫，一旦運營商增加某個號段，對程序的維護人員來說就是一個噩耗。這時，可以使用自定義校驗注解來代替這些常用的校驗。
手機號校驗注解 phone：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
@constraint(validatedby = phonevalidator.class)@target({elementtype.method, elementtype.field})@retention(retentionpolicy.runtime)@documentedpublic @interface phone { string message() default "手機號格式不合法"; class<?>[] groups() default {}; class<? extends payload>[] payload() default {};} |
手機號校驗實現類 phonevalidator：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class phonevalidator implements constraintvalidator<phone, string> { private pattern pattern = pattern.compile("1(([38]\\d)|(5[^4&&\\d])|(4[579])|(7[0135678]))\\d{8}"); @override public void initialize(phone phone) { } @override public boolean isvalid(string value, constraintvalidatorcontext constraintvalidatorcontext) { return pattern.matcher(value).matches(); }} |
model 上的使用：
|
1
2
3
4
|
@phonepublic string getusername() { return username;} |
這樣的話，如果因為某些不可抗拒因素導致校驗規則的變動，只需要修改一處理即可，維護成本大大降低。
4. xml 報文
大多數情況下，使用 json 就可以滿足我們的需求了，但仍然存在某些特定的場景需要使用到 xml 形式的報文，如：微信公眾號開發。不過不用擔心，切換成 xml 報文也只需要做輕微的改動，添加相關依賴如下："com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.8.8"
然后就可以開始進行測試了，此處借助一個模擬 http 請求工具（postman）來協助我們測試該接口：
在上面的測試范例里，我們指定了 accept 為 text/xml，這樣 springboot 就會返回 xml 形式的數據。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://www.cnblogs.com/stillcoolme/p/7678883.html
