目錄
1.MVC的定義
2.SpringMVC的實際應用
(1)建立連接
1.@RequestMapping注解介紹
2.@RequestMapping注解的請求方式
GET請求:
POST請求:
指定GET/POST方法類型:
(2)請求
傳遞參數
1.傳遞單個參數
2.傳遞多個參數
3.傳遞對象
4.后端參數重命名
5.傳遞數組
6.傳遞集合
7.傳遞JSON對象
8.獲取URL中參數@PathVariable
9.上傳文件@RequestPart
10.獲取Cookie/Session
介紹Cookie&Session:
Cookie和Session的區別
獲取Cookie
一般獲取Cookie:
簡潔獲取Cookie:
獲取Session
Session存儲
Session獲取
簡潔獲取Session(1)
簡潔獲取Session(2)
獲取Header
一般獲取Header
簡潔獲取Header
(3)響應
RestController和Controller注解:
返回數據@ResponseBody:
返回HTML代碼片段:
返回JSON:
設置Content-Type:
設置狀態碼:
設置Header:
1.MVC的定義
MVC是Model View Controller的縮寫,是軟件工程的一種軟件架構設計模式,它把軟件系統分為模型、視圖、控制器三個基本部分,如下圖所示:
對于MVC,在集成開發環境idea中同樣封裝有,具體使用方式是依靠注解的形式來使用。
在講解springMVC之前,我們需要了解一下瀏覽器和服務器是如何進行交互的。
使用瀏覽器來對服務器發送請求,我們就需要了解URL的相對格式,如拿京東搜索商品舉例:
對于本機的ip可以使用localhost或者127.0.0.1,運行本機web端的端口號使用8080。
瀏覽器和服務器的交互基本如下:
在本機,我們可以利用postman來模擬發送請求,并且關注每個注釋不同的用法。
2.SpringMVC的實際應用
(1)建立連接
在idea中創建好spring框架,加載meven項目,會發現main文件夾路徑下會有一DemoApplication類,也就是項目的啟動類:
@SpringBootApplication這個注釋在哪,也就說明該項目的啟動入口在哪里。
在springMVC中,常用@RequestMapping來實現URL的映射,使瀏覽器連接程序。實驗期間,我們也需要使用@RestController,使返回對象以http響應體返回。
1.@RequestMapping注解介紹
@RequestMapping注解既可以修飾類,也可以修飾方法。當修飾類和方法時訪問的地址是類路徑+方法路徑,例如:
可以看見,網址以類路徑+方法路徑的形式輸入,不論類路徑還是方法路徑都可以進行分層,也可以不需要類路徑單獨訪問方法:
2.@RequestMapping注解的請求方式
對于請求,我們有很多種方式可以模擬,比如form表單、postman模擬發送請求。那對于@RequestMapping究竟是get請求還是post請求呢?
GET請求:
瀏覽器發送的請求類型都是get,說明支持get請求
POST請求:
form表單發送:
將前端代碼放入static目錄下,訪問路徑為:127.0.0.1:8080/(html文件名)
點擊提交:
指定GET/POST方法類型:
對于@RequestMapping,都支持GET和POST請求,也可以指定接收固定請求
也可以單獨使用@PostMapping
這樣就只能允許POST請求通過,其他請求不能通過
(2)請求
在測試實驗過程中因為模擬請求而屢次創建修改前端代碼會顯得很麻煩,所以接下來我們將使用postman來完成模擬請求的任務。
首先我們來看看@RequestMapping的內部結構:
傳遞參數
訪問不同路徑,就是發送不同的請求,可能會帶上一些參數,究竟如何傳遞參數?后端如何接收參數?
對于框架中的傳參,都是以Key-Value的形式來存儲的,下面我們以postman來作為請求模擬,學習如何傳遞參數。
1.傳遞單個參數
在查詢字符串段中以鍵值對的形式輸入數據,就可以完成傳參,也可以在postman下方的Params直接輸入鍵和對應的值即可。
2.傳遞多個參數
和傳遞單個參數基本一致,也是以鍵值對的形式輸入,不同的是傳參順序可以隨意(當有多個參數時前后端匹配是以鍵值對的形式,位置不受影響),參數類型必須一致!
3.傳遞對象
當需要傳遞的參數很多時,為了防止代碼冗余難以修改,我們可以封裝一個對象,傳遞該對象的所有參數。
我們先創建出來一個person對象,包含三個屬性:
本質上和傳遞多個參數沒什么區別,只是因為這些參數封裝成一個對象:
若是該對象內的屬性沒有輸入值,則會分配默認值。
4.后端參數重命名
在有些特殊情況下,前端傳遞的參數Key可能跟我們后端的Key不一致,容易出現接收不到的情況,這時我們可以使用@RequestParam來重命名解決后端的參數值(后端參數映射)。
需要注意的是,使用了@RequestParam,參數就變成了必傳參數!
若是真不想傳參數,可以使用required屬性至為false,這樣就變成可傳可不傳了。
5.傳遞數組
SpringMVC可以實現自動綁定數組參數的賦值
6.傳遞集合
和數組傳遞類似,但是需要使用@RequestParam綁定參數關系:
7.傳遞JSON對象
我們先來看json的格式要求:
我們發送JSON數據的時候,再后端可以使用對象接收,使用@RequestBody這個注釋進行json數據的轉換,在postman上也使用json數據發送,比如使用之前創建的Person類接收:
對于@RequestBody這個注釋,主要功能是將HTTP請求體中的數據(JSON,XML)反序列化為java對象。
對于JSON,我們還有更復雜的表示方式:
在上面的JSON數據中包含著對象嵌套數組或者數組嵌套對象這類比較復雜的數據。
通過抓包軟件也可以看到json數據:
8.獲取URL中參數@PathVariable
在前后端交互中,有時候我們需要獲取到URL上面的參數,比如搜索信息的時候獲取該URL上面的序列號將對應的網頁上傳給前端,以便客戶查找到對應的信息:
這時候就可以獲取URL上面的年份日期或者序列號,將對應的網頁上傳給客戶。
對于獲取URL的參數我們使用的是@PathVariable注解,主要作用在請求URL路徑上的數據綁定。
注意的是,在RequestMapping上待定參數用{}號框起來:
9.上傳文件@RequestPart
對于文件,我們可以使用@RequestPart注解來傳輸,比如我們將一張照片傳輸到D盤的temp文件上:
可以看到,文件已經傳輸成功了。
10.獲取Cookie/Session
首先我們要知道,HTTP協議自身是屬于“無狀態”協議,默認情況下HTTP的客戶端和服務器之間的這次通信,和下次通信之間沒有直接的聯系。
但是在實際開發中我們很多時候是需要這些聯系的,例如瀏覽器登錄成功的時候,第二次訪問服務器就知道該請求是否已經登錄過了。
介紹Cookie&Session:
下面以醫院掛號的例子說明一下Cookie和Session機制:
對于Cookie和Session,還可以這樣理解,還是以上述為例:
對于Cookie而言,存取少量信息,包含關鍵的唯一性字符串,也就是SessionId。
對于Session而言,本質上就是一個“哈希表”,存儲了一些鍵值對結構,Key就是SessionID,Value就是用來標識的用戶信息(靈活轉換)。
Cookie和Session的區別
1.Cookie是客戶端保存用戶信息的一種機制,Session是服務端保存用戶信息的一種機制
2.SessionId是Cookie和Session之間的橋梁
3.Cookie和Session經常一起使用,但不是必要:
? ? ? 完全可以用Cookie來報錯一些數據在客戶端,這些數據不一定是用戶身份信息或者SessionId
? ? ? Session中的sessionId也可以使用URL傳遞
獲取Cookie
在此之前,我們先回顧一下http請求的格式,使用fiddler來抓包:
以POST請求為例,在請求中有許多信息,比如URL,請求方式,header,body等參數,響應中也有http狀態碼,響應header和響應正文等信息,我們要是想獲取這些參數,就需要知道倆個對象,這倆對象是Servlet提供的倆個類,是Spring的內置對象:
HttpServletRequest(客戶端請求):當客戶端通過HTTP訪問服務器時,HTTP請求頭中的所有信息都封裝在這個對象中,通過這個對象的方法可以獲取到請求的所有信息。
HttpServletResponse(服務端響應):同理,HTTP的響應信息都在這個對象中,響應頭狀態碼等,通過這個對象的方法可以獲取到服務器響應的所有信息。
一般獲取Cookie:
代碼解析:
postman設置Cookie值:
最后設置成功:
瀏覽器設置Cookie值:
簡潔獲取Cookie:
使用@CookieValue注解
獲取Session
Session是服務器的機制,我們需要先存儲,才能再獲取,對于Session也是基于HttpServletRequest來存儲和獲取的。
一般的Session內部大概是這樣的:
Session存儲
代碼演示:
然后我們使用postman來發送請求:
我們看看fiddler抓包結果:
可以看到,正如上面所說,Cookie和Session是通過SessionID建立聯系,創建Session之后通過Set-Cookie告知客戶端并把SessionID儲存在Cookie中。
通過瀏覽器也可以觀察SessionID:
我們也可以直接省略掉HttpServletRequest使用HttpSession:
Session獲取
獲取Session我們依舊可以使用HttpServletRequest:
簡潔獲取Session(1)
需要使用到@SessionAttribute注解
簡潔獲取Session(2)
通過Spring內置對象HttpSession來獲取(省略HttpServletRequest)
獲取Header
對于header,我們隨機抓一個包來看看:
獲取header也是從HttpServletRequest中獲取的。
對于獲取user-Agent,我們可以采取以下方法:
一般獲取Header
同過抓包軟件我們也可以看到user-Agent:
簡潔獲取Header
該方法用到@RequestHeader注釋
這回我們使用瀏覽器瀏覽:
查看抓包軟件:
(3)響應
對于響應來說,我們前面涉及的都是數據響應,HTTP響應還能響應靜態頁面。在講解響應之前我們先來回顧上面所說到的@RestController注釋:
@RestController是一個組合注解,它結合了@Controller+@ResponseBody的功能,我們可以看看內部:
RestController和Controller注解:
之前我們使用的@RestController是把數據直接寫入到http響應體上,不能直接跳轉到某個頁面上,這是因為該注解中有一個@ResponseBody,如果我們單純使用@Controller,就會發現可以跳轉頁面了,再對比使用@RestController:
我們先創建一個html文件:
@RestController:
@Controller:
返回數據@ResponseBody:
由上面的倆個不一樣的注解我們可以看到,加上了@ResponseBody的注釋的返回值是返回數據到響應體,而沒有加上的@Controller則是直接跳轉到某頁面上,但是需要注意的是:對于返回頁面我們需要在文件前面加上“/”,不像是@RequestMapping一般,加不加都有校驗的地方,這是硬性要求。
對于@ResponseBody,它既是類注解也是方法注解,作用于類上,代表該類的所有方法都是返回數據,作用于方法上代表該方法返回的是數據。
@Controller+@ResponseBody:
返回HTML代碼片段:
對于后端返回數據時,數據中有html代碼也會被瀏覽器解析:
為什么會這樣呢?我們先來看看fiddler抓包結果:
我們再來看幾個常見的Content-Type取值:
text/plain :純文本格式
text/html :body的數據格式是HTML
text/css :body的數據格式是CSS
application/json :body的數據格式是JSON
application/javascript :body的數據格式是JavaScript
http協議會根據請求的文件判斷是什么類型的,然后自動設置Content-Type值返回響應。
返回JSON:
我們也可以返回JSON類型的數據,繼續延用我們上面創建過的Person類:
http成功將響應數據設置為JSON格式,我們再來看看fiddler抓包:
對于后端返回的結果對象或集合,響應頁面自動轉為JSON。
我們再來看組集合的返回:
設置Content-Type:
其實不僅僅是依靠http協議來識別轉換Content-Type,我們也可以通過設置produces屬性的值來設置響應的報頭Content-Type。
我們先來看一個例子:
可以看到,由于返回類型是String類型,默認為字符串,所以http響應默認轉換為html的格式。
我們要想讓這個字符串變成JSON格式,需要利用@RequestMapping注解的produces屬性來轉換:
再看看fiddler抓包結果:
設置狀態碼:
我們之前也了解過狀態碼了,但是狀態碼是不是就只能由SpringMVC自己自動設置響應狀態碼,我們能不能設置響應狀態碼呢?
答案是可以的,我們可以手動指定狀態碼,通過SpringMVC的內置對象HttpServletResponse提供的方法設置:
然后我們抓一下包:
發現這里的狀態碼是404,但是我們的頁面還能正常顯示:
所以我們得出結論,在這里設置的狀態碼不影響頁面的展示。
設置Header:
對于我們的Http響應報頭來說有挺多的附加信息,這些信息可以通過@RequestMapping注解的屬性來實現。
?對于@RequestMapping注解,我們可以看看內部結構:
我們還可以設置響應的Header屬性的值,也需要SpringMVC內置對象HttpServletResponse提供的方法來進行設置:
我們來看看fiddler抓包:
可以看到我們已經設置了Header