前言

基于 springboot+vue 的測(cè)試平臺(tái)(練手項(xiàng)目)開(kāi)發(fā)繼續(xù)更新。

今天終于把已做的功能都重構(gòu)完成了。

其中前端又做了個(gè)小調(diào)整，就是入?yún)?dòng)態(tài)增刪的控件，本來(lái)我是3個(gè)tab復(fù)用一個(gè)組件，后來(lái)不斷發(fā)現(xiàn)一些問(wèn)題，最后我決定還是分開(kāi)寫(xiě)吧。

今天另一個(gè)重點(diǎn)是重做了編輯頁(yè)發(fā)送接口請(qǐng)求的后端功能。這個(gè)功能重構(gòu)之前是有的，但是現(xiàn)在我覺(jué)得之前那些做兼容不夠。

因?yàn)槲易罱诠ぷ髦薪尤腼w書(shū)的一些開(kāi)放API，發(fā)現(xiàn)存在一些接口的入?yún)⑹墙M合來(lái)的，比如 post 請(qǐng)求中，既有查詢參數(shù)，也有請(qǐng)求體。

于是我重新梳理一下，盡量支持了各種參數(shù)組合：

• 不帶任何參數(shù)
• 只有 param 查詢參數(shù)
• 只有 rest 路徑參數(shù)
• 只有 body 參數(shù)
• 同時(shí) param + body
• 同時(shí) rest + body

請(qǐng)求方法的話，暫時(shí)還是先支持 get 與 post 這2種最常見(jiàn)的。最后，把各種判斷情況分支都走了一遍，確認(rèn)沒(méi)啥問(wèn)題。

功能實(shí)現(xiàn)

接下來(lái)記錄下功能的實(shí)現(xiàn)。思路很簡(jiǎn)單：

一些必要參數(shù)的獲取與處理不同請(qǐng)求方法的判斷進(jìn)一步判斷不同的參數(shù)組合情況，來(lái)進(jìn)行發(fā)送http接口的處理。

用的 http 客戶端是hutool框架的，代碼位置在項(xiàng)目的這里，93行往后。

首先，主方法前面處理一些必要的入?yún)⑿畔ⅲ热?method、header、以及獲取表單里的參數(shù)。

接下來(lái)進(jìn)入到請(qǐng)求方法的判斷，然后進(jìn)一步判斷目前前端提交過(guò)來(lái)的各種類(lèi)型的參數(shù)情況，這里抽出去寫(xiě)了 2 個(gè)判空的方法。

以 get 方法為例，現(xiàn)在我可以判斷出實(shí)際提交來(lái)的參數(shù)都有誰(shuí)。

判斷出參數(shù)類(lèi)型，就可以針對(duì)性處理了，這里最麻煩的就是 rest 路徑參數(shù)的處理，我前端提交來(lái)的路徑參數(shù)是用花括號(hào)包著的{name}，所以要對(duì)url重新處理一下。

拼接完成后，就可以直接發(fā)起請(qǐng)求了。

這里要注意的是，在hutool的 http 客戶端中，我入?yún)⑹褂?code>body()的時(shí)候會(huì)把form()的參數(shù)覆蓋掉，所以在處理請(qǐng)求體參數(shù)組合的情況下，只能把查詢參數(shù)或者路徑參數(shù)，都處理在請(qǐng)求 url 上。比如，這里是為了處理param+body的組合，手動(dòng)把param參數(shù)拼接到 url 上。

其他就沒(méi)什么特別的了，在 post 中我覺(jué)得沒(méi)必要支持那么多種情況，所以只兼容了 3 種情況。

目前只是一個(gè)功能實(shí)現(xiàn)的訴求，還缺少一些異常的處理，后續(xù)慢慢補(bǔ)上。接下來(lái)會(huì)繼續(xù)新功能的開(kāi)發(fā)，過(guò)程中也會(huì)帶著改一些我記錄下來(lái)的 bug 。

前后端的最新代碼都已經(jīng)更新到分支上

前端：

https://github.com/wessonlan/bloomtest-web

后端

https://github.com/wessonlan/bloomtest-backend

以上就是springboot+vue完成編輯頁(yè)發(fā)送接口請(qǐng)求功能的詳細(xì)內(nèi)容，更多關(guān)于編輯頁(yè)發(fā)送接口請(qǐng)求的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！