如何正確的使用@RequestBody

本篇文章為大家展示了如何正確的使用@RequestBody，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

基礎知識介紹：

@RequestBody主要用來接收前端傳遞給后端的json字符串中的數據的(請求體中的數據的)；GET方式無請求體，所以使用@RequestBody接收數據時，前端不能使用GET方式提交數據，而是用POST方式進行提交。在后端的同一個接收方法里，@RequestBody與@RequestParam()可以同時使用，@RequestBody最多只能有一個，而@RequestParam()可以有多個。

注：一個請求，只有一個RequestBody；一個請求，可以有多個RequestParam。

注：當同時使用@RequestParam（）和@RequestBody時，@RequestParam（）指定的參數可以是普通元素、
數組、集合、對象等等(即:當，@RequestBody 與@RequestParam()可以同時使用時，原SpringMVC接收
參數的機制不變，只不過RequestBody 接收的是請求體里面的數據；而RequestParam接收的是key-value
里面的參數，所以它會被切面進行處理從而可以用普通元素、數組、集合、對象等接收)。
即：如果參數時放在請求體中，傳入后臺的話，那么后臺要用@RequestBody才能接收到；如果不是放在
請求體中的話，那么后臺接收前臺傳過來的參數時，要用@RequestParam來接收，或則形參前
什么也不寫也能接收。

注：如果參數前寫了@RequestParam(xxx)，那么前端必須有對應的xxx名字才行(不管其是否有值，當然可以通
過設置該注解的required屬性來調節是否必須傳)，如果沒有xxx名的話，那么請求會出錯，報400。

注：如果參數前不寫@RequestParam(xxx)的話，那么就前端可以有可以沒有對應的xxx名字才行，如果有xxx名
的話，那么就會自動匹配；沒有的話，請求也能正確發送。
追注：這里與feign消費服務時不同；feign消費服務時，如果參數前什么也不寫，那么會被默認是
@RequestBody的。

如果后端參數是一個對象，且該參數前是以@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方法將值賦給該屬性。

上述內容就是如何正確的使用@RequestBody，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。