您好,登錄后才能下訂單哦!
這篇文章主要介紹“postman使用@ResquetBody和@RequestParam需要注意什么”,在日常操作中,相信很多人在postman使用@ResquetBody和@RequestParam需要注意什么問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”postman使用@ResquetBody和@RequestParam需要注意什么”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
如今前后端分離之后,大多采用json格式的數據進行交互,Java后臺一般也就采用發現用@ResquetBody和@RequestParam兩個注解進行接收參數。
常規做法是:
@ResquetBody用來接收一個復雜的包裝類型,比如:
@RequestBody AuthApplyDto authDto
@Data public class AuthApplyDto { private int id; private String status=""; private String userId=""; ... }
@ResquetParam用于接收基本類型或者基本類型及String對象。當然,如果請求參數不復雜,使用多個@ResquetParam也可達到@ResquetBody同樣的效果(如果參數不多的時候)。
但是,很有可能你會遇到下面的情況:
"Required String parameter 'userid' is not present"
此時,你需要重新審視這兩個注解的使用場景了。
后臺參數接收如下:
@RequestParam(name="userid") String userId, @RequestParam(name="resourceid") String resourceId)
情況一:get方式請求,請求參數如下:
{ "userid":1, "resourceid":"18" }
測試結果:后臺可以接收。
情況二:post方式請求,json序列化傳遞,請求參數同上。后臺報錯如下:
呵呵,這個幾個意思,明明傳遞了userid,卻提示我沒有傳,不科學啊!!!仔細一想,問題肯定出在后臺對參數的解析上。
情況三:同時注意到,如果采用form-data的方式則可以成功請求。
情況四:如果采用x-www-form-urlencoded的方式也可以成功請求
那為什么同樣是post請求,json格式的數據卻無法解析。這是因為第三種和第四種都是以表單數據提交,content-Type并不是application/json。更多詳情參見:四種常見的 POST 提交數據方式
也就是說Content-Type = application/x-www-form-urlencoded(或者 multipart/form-data) 的編碼方式,二者是表單請求,可以用@RequestParam一個一個獲取參數。而 Content-Type = application/json 的時候參數獲取不到。并且會報錯:
- Required String parameter ‘xx’ is not present
那對于application/json的編碼,應該怎么接收呢,答案則是@RequestBody。此注解能夠做json格式的解碼和編碼。
后臺參數接收:
@RequestBody AuthApplyDto authDto
情況一:json格式傳遞,post請求,測試結果成功。
情況二:如果使用@RequestBody接收參數,使用表單格式post請求,又會發生什么呢?答案是不支持。
情況三:如果,請求方式為get,后臺參數接收@RequestBody ,如下格式,會發生什么呢??答案是肯定的。
測試結果如下:
疑問,這兩個注解底層如何做適配解析的?
如果請求數據為數組,比如:
{ "ids":[1,2] }
后臺需要做如下包裝,便可接收。
@RequestBody DeleteIds ids, @Data public class DeleteIds { private Set<Integer> ids; }
到此,關于“postman使用@ResquetBody和@RequestParam需要注意什么”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。