SpringMvc自動裝箱及GET請求參數(shù)原理解析
在我的概念里邊,GET請求需要加上注解@RequestParam,然后它的參數(shù)類型只能是 基本數(shù)據(jù)類型 或者 基本數(shù)據(jù)類型的包裝類,比如:@RequestParam String name(默認(rèn)是必傳的),也可以不加@RequestParam 注解,其實(shí)就相當(dāng)于@RequestParam(required = false)
但是參數(shù)類型竟然是自定義對象,對象類里有不同的參數(shù)和get/set方法,而且沒有使用@RequestParam 注解,那么同樣也能實(shí)現(xiàn)GET請求
比如一個請求方法是:public String login(User user) ,User.java類里有name 和password 兩個參數(shù)和get/set方法
那么請求http://localhost:8080/login?name=admin&password=123456是完全沒問題的
自動裝箱理解
對Java自動裝箱、拆箱的理解是:裝箱就是自動將基本數(shù)據(jù)類型轉(zhuǎn)換為包裝器類型;拆箱就是自動將包裝器類型轉(zhuǎn)換為基本數(shù)據(jù)類型。
對于springmvc來說,感覺它的自動裝箱,是將多個一般類型的參數(shù)轉(zhuǎn)換成一個對象,并賦值到對象里的變量
那么這樣的請求參數(shù)如何限制是否必傳呢?這里可沒有(required = true),那就需要使用@Valid注解了
自動裝箱的缺點(diǎn)
1、自動裝箱最直接的缺點(diǎn)就是效率低,不解釋
2、我們知道url請求會放到RequestHeader 里,這個應(yīng)該是有長度限制的,那么太長了肯定不合適。如果是POST請求的話,會放到RequestBody里面去,就不會有RequestHeader 過長的問題了
3、如果對象里放的是List 類型的參數(shù),那么這個應(yīng)該如何在url 里進(jìn)行GET請求呢?我問老大,他說要避免這種情形,使用JSON格式
POST請求的自動裝箱
POST請求的參數(shù),一般都加上注解@RequestBody,但是上例中的public String login(User user) 方法即使使用POST請求,依然是可以執(zhí)行的
網(wǎng)上搜了下么springmvc在post請求時使用與不使用@RequestBody注解的區(qū)別?
不使用@RequestBody注解時,可以接收Content-Type為application/x-www-form-urlencoded類型的請求所提交的數(shù)據(jù),數(shù)據(jù)格式:aaa=111bbb=222。form表單提交以及jQuery的.post()方法所發(fā)送的請求就是這種類型。
使用@RequestBody注解時,用于接收Content-Type為application/json類型的請求,數(shù)據(jù)類型是JSON:{"aaa":"111","bbb":"222"}
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
Spring AOP手動實(shí)現(xiàn)簡單動態(tài)代理的代碼
今天小編就為大家分享一篇關(guān)于Spring AOP手動實(shí)現(xiàn)簡單動態(tài)代理的代碼,小編覺得內(nèi)容挺不錯的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來看看吧2019-03-03SpringCloud使用Kafka Streams實(shí)現(xiàn)實(shí)時數(shù)據(jù)處理
使用Kafka Streams在Spring Cloud中實(shí)現(xiàn)實(shí)時數(shù)據(jù)處理可以幫助我們構(gòu)建可擴(kuò)展、高性能的實(shí)時數(shù)據(jù)處理應(yīng)用,Kafka Streams是一個基于Kafka的流處理庫,本文介紹了如何在SpringCloud中使用Kafka Streams實(shí)現(xiàn)實(shí)時數(shù)據(jù)處理,需要的朋友可以參考下2024-07-07