當前位置：首頁 > 前端技术 > vue >内容正文

vue

vue的post请求data可以传两个参吗_我知道的HTTP请求

發布時間：2025/3/21 vue 16 豆豆

生活随笔收集整理的這篇文章主要介紹了 vue的post请求data可以传两个参吗_我知道的HTTP请求小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

HTTP大家都不陌生，但是HTTP的許多細節就并不是很多人都知道了，本文將討論一些容易被忽略但又比較重要的點。

首先，怎么用原生JS寫一個GET請求呢？如下代碼，只需3行：

let xhr = new XMLHttpRequest(); xhr.open("GET", "/list"); xhr.send();

xhr.open第一個參數是請求方法，第二個參數是請求url，然后把它send出去就行了。

如果需要加上請求參數，如果用jQuery的ajax，那么是這么寫的：

$.ajax({url: "/list",data: {page: 5} });

如果是用原生的話就得拼在請求url上面，即open的第二個參數：

并且參數需要轉義，如下代碼所示：

那為什么用jQuery就不用呢？因為jQuery幫我們做了，jQuery的ajax支持一個叫processData的參數，默認為true：

$.ajax({url: "/list",data: {page: 5},processData: true });

這個參數的作用是用來處理傳進來的data的，如下jQuery的源碼：

如果傳了data，并且processData為true，并且data不是一個string了，就會調param處理data。然后我們來看下這個param函數是怎么實現的：

可以看到，它也是跟我自己實現的ajax類似，把key和value轉義用"="拼接，然后push到一個數組，最后再join地一下。不一樣的地方是它的判斷邏輯比我的復雜，它會再調一個buildParams的函數去處理key/value，因為value可能是一個數組，也可能是一個Object。如果value是一個Object，那么直接encode一下就會變成"[object Object]"的轉義了：

所以buildParams在處理每個key/value時，會先判斷當前value是否是一個數組或者是Object，如下圖所示：

如果它是一個數組的話，這個數組的每一個元素都會變成單獨的一個請求字段，它的key是父級的key拼上數組的索引得到，如{ids: [1, 2, 3]}就會被拼成：ids[0]=1、ids[1] = 2、ids[2] = 3，如果是一個Object的話key的后綴就是子Object的key，如{user: {id: 1333, name: "yin"}}會被拼成：user[id]=1333、user[name]=yin，否則就認為它是一個簡單的類型，就直接調一下param函數定義的add，把它push到s那個數組。這里用到了遞歸調用，會不斷地拼key值，直到value是一個普通變量了，就到了最后面的else邏輯。

也就是說，以下代碼：

$.ajax({url: "/list",data: {user: {name: "yin",age: 18}}, });

將會被拼成的url為：

/list?user[name]=yin&user[age]=18

注意上面的中括號還沒有轉義。而如果是一個數組的話：

$.ajax({url: "/list",data: {ids: [1, 2, 3]}, });

拼成的請求url為：

/list?ids[0]=1&ids[1]=2&ids[2]=3

如果后端用的Java的Spring MVC框架的話，是理解這種格式的，框架收到這樣的參數后會生成一個Array，傳遞給業務代碼，業務代碼是不用關心怎么處理這種參數的。其它的框架應該也類似。

怎么用原生JS寫一個POST請求呢？如下圖所示：

POST請求的參數就不是放在url了，而是放在send里面，即請求體。你可能會問：難道就不能放url么？我就要放url。如果你夠任性，那么可以，前提是后端所使用的http框架能夠在url里面取數據，因為它一定會收到url，也一定會收到請求體，所以取決于它要怎么處理，按照http標準，如果請求方法是POST，那么應該是得去請求體拿的，就不會在url的search上取了，當然它可以改一下，改成兩個都可以拿。

然后我們會發現請求的mime類型是text/plain：

并且查看請求參數的時候，并不是平時所看到能夠按照字段一行行地展示：

這是為什么呢？這是因為我們沒有設置它的Content-Type，如下代碼：

let xhr = new XMLHttpRequest(); xhr.open("POST", "/add"); xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); xhr.send("id=5&name=yin");

如果設置Content-Type為x-www-form-urlencoded的話，那么在檢查的話，Chrome也會按字段分行展示了：

這個也是jQuery默認的Content-Type：

它是一種最常用的一種請求編碼方式，支持GET/POST等方法，特點是：所有的數據變成鍵值對的形式key1=value1&key2=value2的形式，并且特殊字符需要轉義成utf-8編號，如空格會變成%20：

由于中文在utf-8需要占用3個字節，所以它有3個%符號。

我們剛剛是xhr.send一個字符串，如果send一個Object會怎么樣呢？如下代碼所示：

let xhr = new XMLHttpRequest(); xhr.open("POST", "/add"); xhr.send({id:5, name: "yin"});

檢查控制臺的時候是這樣的：

也就是說，實際上是調了Object的toString方法。所以可以看到，在send的數據需要轉成字符串。

除了字符串之外，send還支持FormData/Blob等格式，如：

let form = $("form")[0]; xhr.send(new FormData(form));

但最后都是被轉成字符串發送。

我們再看下其它的請求格式，如Github的REST API是使用json的格式發請求：

這個時候要求格式要變成json，就需要指定Content-Type為application/json，然后send的數據要stringify一下：

let xhr = new XMLHttpRequest(); xhr.open("POST", "/add"); xhr.setRequestHeader("Content-type", "application/json"); let data = {id:5, name: "yin"}; xhr.send(JSON.stringify(data));

如果是用jQuery的話，那么可以這樣：

$.ajax({processData: false,data: JSON.stringify(data),contentType: "application/json" });

這個時候processData為false，告訴jQuery不要處理數據了——即拼成key1=value1&key2=value2的形式，直接把傳給它的數據send就好了。

我們可以比較json和urlencoded這兩種形式的優缺點，json的缺點是parse解析的工作量要明顯高于split("&")的工作量，但是json的優點又在于表達復雜結構的時候比較簡潔，如二維數組(m * n)在urlencoded需要拆成m * n個字段，而json就不用了。所以相對來說，如果請求數據結構比較簡單應該是使用常用的urlencoded比較有利，而比較復雜時使用json比較有利。通常來說比較常用的還是urlencoded.

還有第3種常見的編碼是multipart/form-data，這種也可以用來發請求，如下代碼所示：

let formData = new FormData(); formData.append("id", 5); // 數字5會被立即轉換成字符串 "5" formData.append("name", "#yin"); // formData.append("file", input.files[0]); let xhr = new XMLHttpRequest(); xhr.open("POST", "/add"); xhr.send(formData);

它通常用于上傳文件，上傳文件必須要使用這種格式。上面代碼發送的內容如下圖所示：

每個字段之間用一個隨機字符串隔開，保證發送的內容不會出現這個字符串，這樣發送的內容就不需要進行轉義了，因為如果文件很大的話，轉義需要花費相當的時間，體積也可能會成倍地增長。

然后再討論一個問題，我們知道在瀏覽器地址欄輸入一個網址請求數據，這個時候是用的GET請求，而我們在代碼里面用ajax發的GET請求也是GET，瀏覽器訪問網址的GET和ajax的GET有什么區別嗎？

為了能夠觀察到瀏覽器自已發出去的GET，需要用一個抓包工具看一下這個GET是怎么樣的，如下圖所示：

瀏覽器自己發的GET有一個明顯的特點，它會設置http請求頭的Accept字段，并且把text/html排在第一位，即它最希望收到的是html格式。而動態的ajax抓包顯示是這樣的：

可以看到，使用地址欄訪問的和使用ajax的get請求本質上都是一樣的，只是使用ajax我們可以設置http請求頭，而使用地址欄訪問的是由瀏覽器添加默認的請求頭。

上面是使用http抓的包，我們可以看到請求的完整url，包括請求的參數，而如果是抓的https的包的話，GET放在url上的參數就看不到了：

也就是說https的請求報文是加密的，包括請求的uri等，需要解密后才能看到。那是不是說使用https的GET也是安全的，而不是https的POST不會比GET安全？

我們先來看一下http的請求報文，如下圖所示：

如果使用抓包工具的話，可以看到請求報文確實是按照上圖排列的，如圖所示的GET：

而POST是這樣的：

所以本質上GET/POST是一樣的，只是GET把數據拼到url，而POST是放到請求體。另外一點，url是有長度限制的，包括瀏覽器和接收的服務如nginx，而請求體是沒有限制的（瀏覽器沒有限制，但是一般nginx接收會有限制），還有POST的數據支持多種編碼格式。

雖然如此，POST還是比GET安全的，體現在以下幾點：

GET參數是放在url上面，用戶可以保存為書簽、傳播鏈接，如果參數有敏感數據，如登陸的密碼，那么可能會泄露

搜索引擎在爬取網站的時候如果修改數據庫的請求支持GET，那么很可能數據庫會無意被搜索引擎修改

script/img等標簽是GET請求，會更加方便跨站請求偽造，在瀏覽器地址欄輸入也是GET，也是為修改請求提供便利

接著討論請求響應狀態碼。很多人都知道200、404、500這幾個，對于其它的可能就不甚了解了。這里我把一些常用的狀態碼列一下。

1. 301 永久轉移

當你想換域名的時候，就可以使用301，如之前的域名叫http://www.renfed.com，后來換了一個新域名http://www.rrfed.com，希望用戶訪問老域名的時候能夠自動跳轉到新的域名，那么就可以使用nginx返回301：

server {listen 80;server_name www.renfed.com;root /home/fed/wordpress;return 301 https://www.rrfed.com$request_uri; }

瀏覽器收到301之后，就會自動跳轉了。搜索引擎在爬的時候如果發現是301，在若干天之后它會把之前收錄的網頁的域名給換了。

還有一個場景，如果希望訪問http的時候自動跳轉到https也是可以用301，因為如果直接在瀏覽器地址欄輸入域名然后按回車，前面沒有帶https，那么是默認的http協議，這個時候我們希望用戶能夠訪問安全的https的，不要訪問http的，所以要做一個重定向，也可以使用301，如：

server {listen 80; server_name www.rrfed.com;if ($scheme != "https") {return 301 https://$host$request_uri;} }

2. 302 Found 資源暫時轉移

很多短鏈接跳轉長鏈接就是使用的302，如下圖所示：

3. 304 Not Modified 沒有修改

在本地使用webpack-dev-server開發的時候，如果沒有改js/css，那么刷新頁面的時候請求本地的js/css文件將返回304，如下圖所示：

webpack-dev-server的服務怎么知道沒有修改呢，因為瀏覽器在請求的時候帶上了etag，如：

W/"10e632-Oz38I6asQyS459XpsaJYkjMUoZI"

服務會計算當前文件的etag，它是一個文件的哈希值，然后比較一下傳過來的etag，如果相等，則認為沒有修改返回304。如果有修改的話就會返回200和文件的內容，并重新給瀏覽器一個新的etag。下次請求的時候瀏覽器就會帶上這個新的etag。如果把控制臺的disable cached打開的話，那么瀏覽器即使有etag也不會帶上。另外一個判斷有沒有修改的字段是Last Modified Time，這是根據文件的修改時間。

4. 400 Bad Request 請求無效

當必要參數缺失、參數格式不對時，后端通常會返回400，如下圖所示：

并帶上了提示信息：

{"message":"opportunityId type mismatch required type 'long' "}

通過400可以知道請求參數有誤，結合提示信息，說明需要傳一個數字，而不是字符串。

5. 403 Forbidden 拒絕服務

服務能夠理解你的請求，包括傳參正確，但是拒絕提供服務。例如，服務允許直接訪問靜態文件：

但是不允許訪問某個目錄：

否則，別人對你服務器上的文件就一覽無遺了。

403和401的區別在于，401是沒有認證，沒有登陸驗證之類的錯誤。

6. 500 內部服務器錯誤

如業務代碼出現了異常沒有捕獲，被tomcat捕獲了，就會返回500錯誤：

如：數據庫字段長度限制為30個字符，如果沒有判斷直接插入一條31個字符的記錄，就會導致數據庫拋異常，如果異常沒有捕獲處理，就直接返回500。

當服務徹底掛了，連返回都沒有的時候，那么就是502了。

7. 502 Bad Gateway 網關錯誤

如下圖所示：

這種情況是因為nginx收到請求，但是請求沒有打過去，可能是因為業務服務掛了，或者是打過去的端口號寫錯了：

server {location / {# webpack的服務proxy_pass https://127.0.0.1:7071;} }

nginx返回了502.

8. 504 Gateway Timeout 網關超時

通常是因為服務處理請求太久，導致超時，如PHP服務默認的請求響應最長處理時間為30s，如果超過30s，將會掛掉，返回504，如下圖所示：

這種情況可能是因為服務還要請求第三方的服務，第三方服務處理時間較久沒有返回，如在向FCM發送Push的時候，如果一個請求里面需要發送的訂閱的瀏覽器(subscriptions)太多了，就經常會處理很久，導致504.

9. 101 協議轉換

websocket是從http升級而來，在建立連接前需要先通過http進行協議升級：

還有一個600，600是一種不太常用的狀態碼，表示服務器沒有返回響應頭部，只返回實體內容。

這些狀態碼實際上就是一個數字，可以任意返回，但是最好是按照http的規定返回合適的狀態碼。如果返回4、5、6開頭的http狀態碼，瀏覽器將會打印錯誤，認為當前請求失敗。

我們還沒有說怎么判斷請求成功了，如下代碼所示：

xhr.open("POST", UPLOAD_URL); xhr.onreadystatechange = function() {// readyState為4表示請求完成if (this.readyState === 4){if (this.status === 200) {let response = JSON.parse(this.responseText);if (!response.status || response.status.code !== 0) {// 失敗 callback.failed && callback.failed();} else { // 成功 callback.success(response.data.url);} } else if (this.status >= 400 || this.status === 0) {// 失敗 callback.failed && callback.failed();// 正常不應該返回20幾的狀態碼，這種情況也認為是失敗} else { callback.failed && callback.failed();}} }; xhr.send(formData);

這里有個問題，如果返回的狀態碼是3開頭的重定向，需要自己再去發一個請求嗎？

實踐證明，不需要，瀏覽器會自動重定向，如下圖所示：

最后，本文提到了3種常用的請求編碼，分別是application/www-x-form-urlencoded、application/json、multipart/form-data，第一種是最常用的一種，適用于GET/POST等，第二種常見于請求響應的數據格式，第三種通常用于上傳文件。然后還比較了POST和GET，雖然兩者的請求數據都在http報文里面，只是位置不一樣，但是考慮到用戶、搜索引擎等使用場景，POST還是會比GET更安全。最后說了幾個常用的http狀態碼，并用一些實際的例子加深印象和理解。

總結

以上是生活随笔為你收集整理的vue的post请求data可以传两个参吗_我知道的HTTP请求的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： lavaral中文手册_【laravel
下一篇： python读取一个图像_从图像处理py