@RequestBody的使用詳解
提示:建議一定要看後面的@RequestBody的核心邏輯原始碼以及六個重要結論!本文前半部分的內容都是一些基
本知識常識,可選擇性跳過。
宣告:本文是基於SpringBoot,進行的演示說明。
基礎知識介紹:
@RequestBody主要用來接收前端傳遞給後端的json字串中的資料的(請求體中的資料的);GET方式無請求體,所以使用@RequestBody接收資料時,前端不能使用GET方式提交資料,而是用POST方式進行提交。在後端的同一個接收方法裡,@RequestBody與@RequestParam()可以同時使用,@RequestBody最多隻能有一個,而@RequestParam()可以有多個。
注:一個請求,只有一個RequestBody;一個請求,可以有多個RequestParam。
注:當同時使用@RequestParam()和@RequestBody時,@RequestParam()指定的引數可以是普通元素、
陣列、集合、物件等等(即:當,@RequestBody 與@RequestParam()可以同時使用時,原SpringMVC接收
引數的機制不變,只不過RequestBody 接收的是請求體裡面的資料;而RequestParam接收的是key-value
裡面的引數,所以它會被切面進行處理從而可以用普通元素、陣列、集合、物件等接收)。
即:如果引數時放在請求體中,傳入後臺的話,那麼後臺要用@RequestBody才能接收到;如果不是放在
什麼也不寫也能接收。
注:如果引數前寫了@RequestParam(xxx),那麼前端必須有對應的xxx名字才行(不管其是否有值,當然可以通
過設定該註解的required屬性來調節是否必須傳),如果沒有xxx名的話,那麼請求會出錯,報400。
注:如果引數前不寫@RequestParam(xxx)的話,那麼就前端可以有可以沒有對應的xxx名字才行,如果有xxx名
的話,那麼就會自動匹配;沒有的話,請求也能正確傳送。
追注:這裡與feign消費服務時不同;feign消費服務時,如果引數前什麼也不寫,那麼會被預設是
如果後端引數是一個物件,且該引數前是以@RequestBody修飾的,那麼前端傳遞json引數時,必須滿足以下要求:
後端@RequestBody註解對應的類在將HTTP的輸入流(含請求體)裝配到目標類(即:@RequestBody後面的類)時,會根據json字串中的key來匹配對應實體類的屬性,如果匹配一致且json中的該key對應的值符合(或可轉換為),這一條我會在下面詳細分析,其他的都可簡單略過,但是本文末的核心邏輯程式碼以及幾個結論一定要看! 實體類的對應屬性的型別要求時,會呼叫實體類的setter方法將值賦給該屬性。
json字串中,如果value為""的話,後端對應屬性如果是String型別的,那麼接受到的就是"",如果是後端屬性的型別是Integer、Double等型別,那麼接收到的就是null。
json字串中,如果value為null的話,後端對應收到的就是null。
如果某個引數沒有value的話,在傳json字串給後端時,要麼乾脆就不把該欄位寫到json字串中;要麼寫value時, 必須有值,null 或""都行。千萬不能有類似"stature":,這樣的寫法,如:
注:關於@RequestParam()的用法,這裡就不再一一說明了,可詳見 《程式設計師成長筆記(一)》中的相關章節。
示例詳細說明:
先給出兩個等下要用到的實體類
User實體類:
Team實體類:
@RequestBody直接以String接收前端傳過來的json資料:
後端對應的Controller:
使用PostMan測試:
@RequestBody以簡單物件接收前端傳過來的json資料:
後端對應的Controller:
使用PostMan測試:
@RequestBody以複雜物件接收前端傳過來的json資料:
後端對應的Controller:
使用PostMan測試:
@RequestBody與簡單的@RequestParam()同時使用:
後端對應的Controller:
使用PostMan測試:
@RequestBody與複雜的@RequestParam()同時使用:
後端對應的Controller:
使用PostMan測試:
@RequestBody接收請求體中的json資料;不加註解接收URL中的資料並組裝為物件:
後端對應的Controller:
使用PostMan測試:
注:如果在後端方法引數前,指定了@RequestParam()的話,那麼前端必須要有對應欄位才行(當然可以通過設定
該註解的required屬性來調節是否必須傳),否者會報錯;如果引數前沒有任何該註解,那麼前端可以傳,也可
以不傳,如:
上圖中,如果我們傳參中沒有指定token,那麼請求能正常進去,但是token為null;如果在String token前指定了@RequestParam(“token”),那麼前端必須要有token這個鍵時,請求才能正常進去,否者報400錯誤。
@RequestBody與前端傳過來的json資料的匹配規則
宣告:根據不同的Content-Type等情況,Spring-MVC會採取不同的HttpMessageConverter實現來進行資訊轉換解析。
下面介紹的是最常用的:前端以Content-Type 為application/json,傳遞json字串資料;後端以@RequestBody
模型接收資料的情況。
解析json資料大體流程概述:
Http傳遞請求體資訊,最終會被封裝進com.fasterxml.jackson.core.json.UTF8StreamJsonParser中(提示:Spring採用CharacterEncodingFilter設定了預設編碼為UTF-8),然後在public class BeanDeserializer extends BeanDeserializerBase implements java.io.Serializable中,通過 public Object deserializeFromObject(JsonParser p,DeserializationContext ctxt) throws IOException方法進行解析。
核心邏輯分析示例:
假設前端傳的json串是這樣的: {"name1":"鄧沙利文","age":123,"mot":"我是一隻小小小小鳥~"} 後端的模型只有name和age屬性,以及對應的setter/getter方法;給出一般用到的deserializeFromObject(JsonParser p,DeserializationContext ctxt)方法的核心邏輯:
小技巧之指定模型中的屬性對應什麼key
這裡簡單介紹,更多的可參考:
public class BeanPropertyMap implements Iterable<SettableBeanProperty>,java.io.Serializable
給出Controller中的測試類:
給出模型中的屬性(setter/getter方法沒截出來):
使用postman測試一下,示例:
上圖簡單測試了一下,但是測得並不全面,這裡就不帶大家一起測試了,直接給出。
全面的結論:
結論①:@JsonAlias註解,實現:json轉模型時,使json中的特定key能轉化為特定的模型屬性;但是模型轉json時,對應的轉換後的key仍然與屬性名一致,見:上圖示例中的name欄位的請求與響應。
以下圖進一步說明:
此時,json字串轉換為模型時,json中key為Name或為name123或為name的都能識別。
結論②:@JsonProperty註解,實現:json轉模型時,使json中的特定key能轉化為指定的模型屬性;同樣的,模型轉json時,對應的轉換後的key為指定的key,見:示例中的motto欄位的請求與響應。
以下圖進一步說明:
此時,json字串轉換為模型時,key為MOTTO的能識別,但key為motto的不能識別。
結論③:@JsonAlias註解需要依賴於setter、getter,而@JsonProperty註解不需要。
結論④:在不考慮上述兩個註解的一般情況下,key與屬性匹配時,預設大小寫敏感。
結論⑤:有多個相同的key的json字串中,轉換為模型時,會以相同的幾個key中,排在最後的那個key的值給模型屬性複製,因為setter會覆蓋原來的值。見示例中的gender屬性。
結論⑥:後端@RequestBody註解對應的類在將HTTP的輸入流(含請求體)裝配到目標類(即:@RequestBody後面的類)時,會根據json字串中的key來匹配對應實體類的屬性,如果匹配一致且json中的該key對應的值符合(或可轉換為)實體類的對應屬性的型別要求時,會呼叫實體類的setter方法將值賦給該屬性。
程式碼託管連結:https://github.com/JustryDeng/PublicRepository/tree/master/Abc_RequestBodyAndRequestParam
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支援我們。