Web后端基礎(基礎知識)

BS架構：Browser/Server，瀏覽器/服務器架構模式。客戶端只需要瀏覽器，應用程序的邏輯和數據都存儲在服務端。
優點：維護方便
缺點：體驗一般

CS架構：Client/Server，客戶端/服務器架構模式。需要單獨開發維護客戶端。
優點：體驗不錯
缺點：開發維護麻煩

請求響應-請求-postman工具

- <font style="color:rgb(44, 44, 44);">Postman是一款功能強大的網頁調試與發送網頁HTTP請求的Chrome插件。</font>

用它可以很好的簡化,可以很清晰的分析出來前后端請求回應的消息內容

請求響應-請求-日期參數&json參數

日期參數

上述演示的都是一些普通的參數，在一些特殊的需求中，可能會涉及到日期類型數據的封裝。比如，如下需求：

因為日期的格式多種多樣（如：2022-12-12 10:05:45 、2022/12/12 10:05:45），那么對于日期類型的參數在進行封裝的時候，需要通過@DateTimeFormat注解，以及其pattern屬性來設置日期的格式。

@DateTimeFormat注解的pattern屬性中指定了哪種日期格式，前端的日期參數就必須按照指定的格式傳遞。
后端controller方法中，需要使用Date類型或LocalDateTime類型，來封裝傳遞的參數。

Controller方法：

@RestController
public class RequestController {//日期時間參數@RequestMapping("/dateParam")public String dateParam(@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") LocalDateTime updateTime){System.out.println(updateTime);return "OK";}
}

Postman測試：

JSON參數

我們學習JSON格式參數，主要從以下兩個方面著手：

Postman在發送請求時，如何傳遞json格式的請求參數
在服務端的controller方法中，如何接收json格式的請求參數

Postman發送JSON格式數據：

服務端Controller方法接收JSON格式數據：

傳遞json格式的參數，在Controller中會使用實體類進行封裝。
封裝規則：JSON數據鍵名與形參對象屬性名相同，定義POJO類型形參即可接收參數。需要使用 @RequestBody標識。

@RequestBody注解：將JSON數據映射到形參的實體類對象中（JSON中的key和實體類中的屬性名保持一致）

實體類：Address

public class Address {private String province;private String city;//省略GET , SET 方法
}

實體類：User

public class User {private String name;private Integer age;private Address address;//省略GET , SET 方法
}

Controller方法：

@RestController
public class RequestController {//JSON參數@RequestMapping("/jsonParam")public String jsonParam(@RequestBody User user){System.out.println(user);return "OK";}
}

Postman測試：

請求響應-請求-路徑參數

在現在的開發中，經常還會直接在請求的URL中傳遞參數。例如：

http://localhost:8080/user/1        
http://localhost:880/user/1/0

上述的這種傳遞請求參數的形式呢，我們稱之為：路徑參數。

學習路徑參數呢，主要掌握在后端的controller方法中，如何接收路徑參數。

路徑參數：

前端：通過請求URL直接傳遞參數，
后端：使用{…}來標識該路徑參數，需要使用@PathVariable獲取路徑參數

Controller方法：

@RestController
public class RequestController {//路徑參數@RequestMapping("/path/{id}")public String pathParam(@PathVariable Integer id){System.out.println(id);return "OK";}
}

Postman測試：

傳遞多個路徑參數：

Postman：

Controller方法：

@RestController
public class RequestController {//路徑參數@RequestMapping("/path/{id}/{name}")public String pathParam2(@PathVariable Integer id, @PathVariable String name){System.out.println(id+ " : " +name);return "OK";}
}

總結

HTTP協議

HTTP概述

介紹

HTTP：Hyper Text Transfer Protocol(超文本傳輸協議)，規定了瀏覽器與服務器之間數據傳輸的規則。

http是互聯網上應用最為廣泛的一種網絡協議
http協議要求：瀏覽器在向服務器發送請求數據時，或是服務器在向瀏覽器發送響應數據時，都必須按照固定的格式進行數據傳輸

如果想知道http協議的數據傳輸格式有哪些，可以打開瀏覽器，點擊F12打開開發者工具，點擊Network(網絡)來查看

瀏覽器向服務器進行請求時，服務器按照固定的格式進行解析：

服務器向瀏覽器進行響應時，瀏覽器按照固定的格式進行解析：

而我們學習HTTP協議，就是來學習請求和響應數據的具體格式內容。

特點：

基于TCP協議: 面向連接，安全

TCP是一種面向連接的(建立連接之前是需要經過三次握手)、可靠的、基于字節流的傳輸層通信協議，在數據傳輸方面更安全

基于請求-響應模型: 一次請求對應一次響應（先請求后響應）

請求和響應是一一對應關系，沒有請求，就沒有響應

HTTP協議是無狀態協議: 對于數據沒有記憶能力。每次請求-響應都是獨立的

無狀態指的是客戶端發送HTTP請求給服務端之后，服務端根據請求響應數據，響應完后，不會記錄任何信息。

缺點: 多次請求間不能共享數據
優點: 速度快
請求之間無法共享數據會引發的問題：
- 如：京東購物。加入購物車和去購物車結算是兩次請求
- 由于HTTP協議的無狀態特性，加入購物車請求響應結束后，并未記錄加入購物車是何商品
- 發起去購物車結算的請求后，因為無法獲取哪些商品加入了購物車，會導致此次請求無法正確展示數據

HTTP請求協議

介紹

請求協議：瀏覽器將數據以請求格式發送到服務器。包括：請求行、請求頭、請求體
GET方式的請求協議：

請求行：HTTP請求中的第一行數據。由：請求方式、資源路徑、協議/版本組成（之間使用空格分隔）
- 請求方式：GET /POST
- 資源路徑：/brand/findAll?name=OPPO&status=1
  - 請求路徑：/brand/findAll
  - 請求參數：name=OPPO&status=1
  - 請求路徑和請求參數之間使用?連接
  - 協議/版本：HTTP/1.1
請求頭第二行開始，上圖黃色部分內容就是請求頭。格式為key: value形式
- http是個無狀態的協議，所以在請求頭設置瀏覽器的一些自身信息和想要響應的形式。這樣服務器在收到信息后，就可以知道是誰，想干什么了
- 常見的HTTP請求頭有:

請求頭	含義
Host	表示請求的主機名
User-Agent	瀏覽器版本。例如：Chrome瀏覽器的標識類似Mozilla/5.0 …Chrome/79 ，IE瀏覽器的標識類似Mozilla/5.0 (Windows NT …)like Gecko
Accept	表示瀏覽器能接收的資源類型，如text/，image/或者/表示所有；
Accept-Language	表示瀏覽器偏好的語言，服務器可以據此返回不同語言的網頁；
Accept-Encoding	表示瀏覽器可以支持的壓縮類型，例如gzip, deflate等。
Content-Type	請求主體的數據類型
Content-Length	數據主體的大小（單位：字節）

舉例說明：服務端可以根據請求頭中的內容來獲取客戶端的相關信息，有了這些信息服務端就可以處理不同的業務需求。

比如:

不同瀏覽器解析HTML和CSS標簽的結果會有不一致，所以就會導致相同的代碼在不同的瀏覽器會出現不同的效果
服務端根據客戶端請求頭中的數據獲取到客戶端的瀏覽器類型，就可以根據不同的瀏覽器設置不同的代碼來達到一致的效果（這就是我們常說的瀏覽器兼容問題）
請求體：存儲請求參數
- GET請求的請求參數在請求行中，故不需要設置請求體

POST方式的請求協議：

請求行(以上圖中紅色部分)：包含請求方式、資源路徑、協議/版本
- 請求方式：POST
- 資源路徑：/brand
- 協議/版本：HTTP/1.1
請求頭(以上圖中黃色部分)
請求體(以上圖中綠色部分) ：存儲請求參數
- 請求體和請求頭之間是有一個空行隔開（作用：用于標記請求頭結束）

GET請求和POST請求的區別：

區別方式	GET請求	POST請求
請求參數	請求參數在請求行中。例：/brand/findAll?name=OPPO&status=1	請求參數在請求體中
請求參數長度	請求參數長度有限制(瀏覽器不同限制也不同)	請求參數長度沒有限制
安全性	安全性低。原因：請求參數暴露在瀏覽器地址欄中。	安全性相對高

獲取請求數據

Web服務器（Tomcat）對HTTP協議的請求數據進行解析，并進行了封裝(HttpServletRequest)，并在調用Controller方法的時候傳遞給了該方法。這樣，就使得程序員不必直接對協議進行操作，讓Web開發更加便捷。

HTTP響應協議

格式介紹

響應協議：服務器將數據以響應格式返回給瀏覽器。包括：響應行、響應頭、響應體

響應行(以上圖中紅色部分)：響應數據的第一行。響應行由協議及版本、響應狀態碼、狀態碼描述組成
- 協議/版本：HTTP/1.1
- 響應狀態碼：200
- 狀態碼描述：OK
響應頭(以上圖中黃色部分)：響應數據的第二行開始。格式為key：value形式
- http是個無狀態的協議，所以可以在請求頭和響應頭中設置一些信息和想要執行的動作，這樣，對方在收到信息后，就可以知道你是誰，你想干什么
- 常見的HTTP響應頭有:

Content-Type：表示該響應內容的類型，例如text/html，image/jpeg ；Content-Length：表示該響應內容的長度（字節數）；Content-Encoding：表示該響應壓縮算法，例如gzip ；Cache-Control：指示客戶端應如何緩存，例如max-age=300表示可以最多緩存300秒 ;Set-Cookie: 告訴瀏覽器為當前頁面所在的域設置cookie ;

響應體(以上圖中綠色部分)：響應數據的最后一部分。存儲響應的數據
- 響應體和響應頭之間有一個空行隔開（作用：用于標記響應頭結束）

響應狀態碼

狀態碼分類	說明
1xx	響應中 — 臨時狀態碼。表示請求已經接受，告訴客戶端應該繼續請求或者如果已經完成則忽略
2xx	成功 — 表示請求已經被成功接收，處理已完成
3xx	重定向 — 重定向到其它地方，讓客戶端再發起一個請求以完成整個處理
4xx	客戶端錯誤 — 處理發生錯誤，責任在客戶端，如：客戶端的請求一個不存在的資源，客戶端未被授權，禁止訪問等
5xx	服務器端錯誤 — 處理發生錯誤，責任在服務端，如：服務端拋出異常，路由出錯，HTTP版本不支持等