一、GET請(qǐng)求

GET 請(qǐng)求用于向指定資源發(fā)出請(qǐng)求，請(qǐng)求中包含了資源的 URL 和請(qǐng)求參數(shù)。服務(wù)器端通過解析請(qǐng)求參數(shù)來返回相應(yīng)的資源，不會(huì)修改服務(wù)器端的狀態(tài)。

1.1 使用方式

使用 GET 請(qǐng)求方式提交的數(shù)據(jù)會(huì)被包含在 URL 中，因此易于被緩存和瀏覽器保存，但也因此不適合用于提交敏感數(shù)據(jù)。

第一種情形：

前端發(fā)送get請(qǐng)求，使用data方式傳遞參數(shù)。

export function empList(query){
  return request({
    url:'/emps/list',
    method:'get',
    data:query
  })
}

后端使用@GetMapping注解，不使用@RequestBody接收參數(shù)

@GetMapping("/list")
public Result listEmp(Emp emp){
       List<Emp> emps = empService.listEmp(emp);
       return Result.success(emps);
}

這種方法實(shí)際接收不到前端傳遞來的參數(shù)，因?yàn)間et請(qǐng)求參數(shù)傳遞不能是data，而應(yīng)該是params。

如果把后端接收參數(shù)方式改為@RequestBody，前端不作改動(dòng)，則請(qǐng)求會(huì)報(bào)400錯(cuò)誤（請(qǐng)求失敗），后端報(bào)缺失需要的請(qǐng)求體，也就是需要Emp參數(shù)，但是前端并沒有傳送過來。

[org.springframework.http.converter.HttpMessageNotReadableException: Required request
body is missing: public cn.cjc.pojo.Result
cn.cjc.controller.EmpController.list(cn.cjc.pojo.Emp)

結(jié)論：在獲取數(shù)據(jù)，即查詢數(shù)據(jù)庫(kù)的時(shí)候，使用get請(qǐng)求方式，使用params的方式傳遞參數(shù)，或者使用url占位符的方式傳遞參數(shù)。不要在查詢操作中使用post方法。

第二種情形：

前端發(fā)送get請(qǐng)求，不使用data方式傳遞參數(shù)

export function selectById(id) {
  return request({
    url: '/emps/'+id,
    method: 'get',
  })
}

后端使用@GetMapping注解，使用@PathVariable接收參數(shù)

@GetMapping("/{id}")
public Result getById(@PathVariable Integer id){
       log.info("根據(jù)ID查詢員工信息, id: {}",id);
       Emp emp = empService.getById(id);
       return Result.success(emp);
}

結(jié)論：當(dāng)前端發(fā)起GET請(qǐng)求時(shí)，若傳遞的是一個(gè)對(duì)象，則后端接收數(shù)據(jù)時(shí)，不需要用@RequestBody來轉(zhuǎn)換JSON串，若傳遞的是一個(gè)具體的值或參數(shù)則后端必須用@PathVariable來接收。

1.2 優(yōu)缺點(diǎn)

GET 請(qǐng)求的優(yōu)點(diǎn)包括：

• 可以被緩存和瀏覽器保存。
• 對(duì)服務(wù)器性能的影響較小。

GET 請(qǐng)求的缺點(diǎn)包括：

• 不適合用于提交敏感數(shù)據(jù)，以為請(qǐng)求參數(shù)會(huì)出現(xiàn)在URL中。
• 僅適用于對(duì)資源進(jìn)行查詢操作，不能修改服務(wù)器端的狀態(tài)。

1.3 應(yīng)用場(chǎng)景

• 獲取資源信息。
• 對(duì)資源進(jìn)行查詢操作。

二、POST請(qǐng)求

POST 請(qǐng)求用于向指定資源提交數(shù)據(jù)，通常會(huì)導(dǎo)致服務(wù)器端的狀態(tài)發(fā)生變化。例如，在 Web 表單中填寫信息并提交時(shí)，就是使用 POST 請(qǐng)求方式將表單數(shù)據(jù)提交到服務(wù)器存儲(chǔ)。

使用 POST 請(qǐng)求方式提交的數(shù)據(jù)會(huì)被包含在請(qǐng)求體中，而不像 GET 請(qǐng)求方式那樣包含在 URL 中。因此，POST 請(qǐng)求可以提交比 GET 更大的數(shù)據(jù)量，并且相對(duì)更安全。

2.1 使用方式

第一種情況：
前端發(fā)送post請(qǐng)求，使用data方式傳遞參數(shù)，傳遞的是一個(gè)對(duì)象

//POST請(qǐng)求，且傳遞的是一個(gè)對(duì)象
export function add(emp) {
  return request({
    url: '/emps',
    method: 'post',
    data: emp
  })
}

后端使用@PostMapping注解，使用@RequestBody接收參數(shù)

@PostMapping
public Result add(@RequestBody Emp emp){
       empService.add(emp);
       return Result.success();
}

結(jié)論： POST請(qǐng)求，一般用于新增或登錄操作，通常傳遞為一個(gè)對(duì)象即一個(gè)JSON串，后端接收時(shí)必須使用@RequestBody注解來標(biāo)識(shí)，用data方式傳遞參數(shù)

第二種按情：

前端發(fā)送post請(qǐng)求，使用params方式傳遞參數(shù)，傳遞的不是一個(gè)對(duì)象，而是一組參數(shù)，比如登錄操作

export function login(username, password) {
    return request({
        url: '/login',
        method: 'post',
        params: {
            username: username,
            password: password
        }
    })
}

后端使用@PostMapping注解，不使用@RequestBody

    @PostMapping("/login")
    public Map doLogin(String username, String password) {
        User user = userService.selUserByName(username);
        Map map = new HashMap();
        if (Objects.isNull(user)) {
            map.put("result", "no");
        } else {
            if (Objects.equals(user.getPassword(), password)) {
                map.put("code", 200);
                map.put("result", "登錄成功");
                //模擬登錄
                System.out.println("登錄成功");
                log.info("登錄成功");
            } else {
                System.out.println("登錄失敗");

                map.put("result", "no");
            }
        }

        return map;
    }

結(jié)論： POST請(qǐng)求，一般用于新增或登錄操作，傳遞一組參數(shù)的時(shí)候，后端接收時(shí)不使用使用@RequestBody注解來標(biāo)識(shí)，用params方式傳遞參數(shù)

2.2 優(yōu)缺點(diǎn)

POST 請(qǐng)求的優(yōu)點(diǎn)包括：

• 可以提交比 GET 更大的數(shù)據(jù)量。
• 相對(duì)更安全，因?yàn)檎?qǐng)求參數(shù)不會(huì)被包含在 URL 中。

POST 請(qǐng)求的缺點(diǎn)包括：

• 對(duì)服務(wù)器性能的影響較大。
• 不適用于對(duì)同一資源進(jìn)行多次操作。

2.3 應(yīng)用場(chǎng)景

• 向服務(wù)器提交表單數(shù)據(jù)。
• 向服務(wù)器上傳文件。
• 創(chuàng)建資源或提交數(shù)據(jù)到服務(wù)器。

三、PUT請(qǐng)求

PUT 請(qǐng)求用于向服務(wù)器更新指定資源，可以理解為對(duì)服務(wù)器上的資源進(jìn)行修改操作。使用 PUT 請(qǐng)求方式會(huì)覆蓋原有的資源內(nèi)容，因此需要謹(jǐn)慎使用。

3.1 使用方式

前端發(fā)送put請(qǐng)求，使用data方式傳遞參數(shù)

export function update(emp) {
  return request({
    url: '/emps',
    method: 'put',
    data: emp
  })
}

后端使用@PutMapping注解，使用@RequestBody接收參數(shù)

@PutMapping
public Result update(@RequestBody Emp emp){
       empService.update(emp);
       return Result.success();
}

如果前端使用data傳遞參數(shù)，后端不使用@RequestBody注解接收參數(shù)，則接收不到前端傳遞過來的參數(shù)（對(duì)象為null）。

如果前端使用params傳遞參數(shù)，后端使用@RequestBody注解接收參數(shù)，則會(huì)報(bào)請(qǐng)求體缺失異常（請(qǐng)求體中需要Emp參數(shù)，但是沒有）。

如果前端使用params傳遞參數(shù)，后端不使用@RequestBody注解接收參數(shù)，是可以接收到前端傳遞過來的參數(shù)（對(duì)象為null）。

雖然可以使用post代替put但是同樣也不建議這樣使用。

結(jié)論：當(dāng)前端發(fā)起PUT請(qǐng)求時(shí)，若傳遞為一個(gè)對(duì)象即一個(gè)JSON串，則后端必須用@RequestBody注解進(jìn)行標(biāo)識(shí)；若傳遞參數(shù)為具體的值，后端接收時(shí)不需要任務(wù)注解進(jìn)行標(biāo)識(shí)。

3.2 優(yōu)缺點(diǎn)

PUT 請(qǐng)求的優(yōu)點(diǎn)包括：

• 可以更新指定的資源。

PUT 請(qǐng)求的缺點(diǎn)包括：

• 對(duì)服務(wù)器性能的影響較大。
• 不適用于對(duì)同一資源進(jìn)行多次操作。

3.３ 應(yīng)用場(chǎng)景

• 更新指定的資源。
• 按照條件更新一組資源。

四、DELETE請(qǐng)求

DELETE 請(qǐng)求用于請(qǐng)求服務(wù)器刪除指定的資源，可以理解為對(duì)服務(wù)器上的資源進(jìn)行刪除操作。使用 DELETE 方式請(qǐng)求會(huì)導(dǎo)致指定的資源被永久刪除，因此需要謹(jǐn)慎使用。

4.1 使用方式

前端使用delete請(qǐng)求方式，傳輸單個(gè)參數(shù)，URL中設(shè)置占位符參數(shù)

//傳輸單個(gè)參數(shù)
export function deleteById(id) {
  return request({
    url: '/depts/' + id,
    method: 'delete'
  })
}

后端使用@DeleteMapping注解，@PathVariable獲取URL參數(shù)

   @GetMapping("/{id}")
    public Region findRegion(@PathVariable Integer id) {
        return regionService.selectById(id);
    }

如果前端使用params傳遞參數(shù)，后端使用@RequestParam，則前端報(bào)400（請(qǐng)求失?。蠖藞?bào)缺少需要的參數(shù)錯(cuò)誤；
前端使用data傳遞參數(shù)，后端使用@RequestParam仍然不行，報(bào)相同的錯(cuò)誤。
使用post請(qǐng)求也可以完成delete的操作，但是不支持這樣做。
結(jié)論：當(dāng)前端發(fā)起DELETE請(qǐng)求時(shí)，傳遞的是一個(gè)具體的值或參數(shù)，后端接收參數(shù)必須用@PathVariable注解進(jìn)行標(biāo)識(shí)。

4.2 優(yōu)缺點(diǎn)

DELETE 請(qǐng)求的優(yōu)點(diǎn)包括：

• 可以永久刪除指定的資源。

DELETE 請(qǐng)求的缺點(diǎn)包括：

• 對(duì)服務(wù)器性能的影響較大。
• 不適用于對(duì)同一資源進(jìn)行多次操作。

4.3 應(yīng)用場(chǎng)景

• 刪除指定的資源。
• 按照條件刪除一組資源。

五.總結(jié)

主要針對(duì)于GET和POST請(qǐng)求：

• GET拼接url，POST傳遞body，get限制字符串長(zhǎng)度

• 請(qǐng)求緩存：GET 會(huì)被緩存，而post不會(huì)，原因是get是url的請(qǐng)求

• 收藏書簽：GET可以，而POST不能，原因是url可以收藏，

• 保留瀏覽器歷史記錄：GET可以，而POST不能，原因是get的url請(qǐng)求

• 用處：get常用于取回?cái)?shù)據(jù)，post用于提交數(shù)據(jù)

• 安全性：post比get安全，是因?yàn)閜ost是請(qǐng)求體，不會(huì)在url上被劫持！

• 請(qǐng)求參數(shù)：querystring是url的一部分get、post都可以帶上。

• get的querystring僅支持urlencode編碼，post的參數(shù)是放在body（支持多種編碼）

• 請(qǐng)求參數(shù)長(zhǎng)度限制：get請(qǐng)求限制字符串長(zhǎng)度 ，post請(qǐng)求不限制字符串長(zhǎng)度

總結(jié) 

到此這篇關(guān)于前端常用的4種請(qǐng)求方式的文章就介紹到這了,更多相關(guān)前端常用請(qǐng)求方式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論