起因
前兩天在做 vue
專案的過程中使用 axios
做介面資料請求,很普通的一個介面,開發的過程中也沒什麼問題。自測的時候鬱悶的發先,每個介面都調了兩次,剛開始沒太注意感覺兩次請求是一摸一樣的,仔細看了一圈,發現第一次呼叫的 Request Method: OPTIONS
,第二次呼叫的 Request Method: POST
。並且 OPTIONS
的請求也損耗了很多的資源。
試想一下,如果每個介面都這樣呼叫兩次,在前端需要多損耗多少資源,這個在複雜專案中的損耗是不可估量的。於是就查了一番資料,看到了很多不同的解決方法,說一下我解決這個問題的方法和問題原因。
解決方案
1. 使用 URLSearchParams
var params = new URLSearchParams()
params.append('param1', 'value1')
params.append('param2', 'value2')
複製程式碼
這裡的 params
就是正確請求介面入參,這樣的操作太複雜了,每次都要這樣生成入引數據,實在太累OUT
2. 使用qs.stringify
- 安裝qs
npm install --save qs
複製程式碼
- axios配置
我這裡把 axios
的封裝寫在了 src/plugins/ajax.js
import axios from 'axios'
import qs from 'qs'
// 新增響應攔截器
axios.interceptors.request.use(
config => {
if (config.method === 'post') {
config.data = qs.stringify(config.data)
}
return config
},
error => {
console.log(error)
Promise.reject(error)
}
)
複製程式碼
這裡我們看一下,其實就是在 axios
發起請求的前攔截請求,當請求型別是 post
的時候,把請求的入引數據 qs.stringify
一下,看一下前後資料格式的對比。
// qs.stringify 前
{
"userId": "520b0ec329164dd9a4f216ba8d209029",
"startTime": "1548950400000",
"endTime": "1551369599999"
}
// qs.stringify 後
"userId=520b0ec329164dd9a4f216ba8d209029&startTime=1548950400000&endTime=1551369599999"
複製程式碼
這時候再去看後臺我發起的請求,OPTIONS
已經不存在啦,只發起了一次正常的 post
請求
但是遺憾的是,雖然介面請求型別正確了,但是介面返回的資料錯了,介面提示沒有獲取到正確的入引數據,跟後端的同學一起看了下,應該是入參的資料型別從
json
變成的string
,後端無法正確獲取到,這裡就需要後端的同學獲取入參格式化一下獲取到的資料。這樣一切就搞定了。
3. 使用Access-Control-Max-Age
這裡說一個最簡單的解決方法,只要後端同學在設定跨域請求資料的時候,新增 Access-Control-Max-Age
,這個引數的意思是把 OPTIONS
快取起來,在指定的時間內,不會再次發起 OPTIONS
預請求,這樣只有在第一次請求的時候會有 OPTIONS
,如果這個時間拉的足夠長,其實並不太損耗資源,這算是一個迂迴解決的方法。
// 後端設定,2592000單位秒,這裡是30天
response.addHeader( "Access-Control-Max-Age", "2592000" )
複製程式碼
在控制檯開啟 Disable cache
,可以看到請求中還有 OPTIONS
,關閉 Disable cache
之後,再看請求已經沒有了 OPTIONS
以上就是我們在 axios
中如果遇到複雜請求 OPTIONS
時候的幾種解決辦法,請各位多指教。