2021-02-28 uni-app資料傳輸前後聯調

項目場景：uni-app資料傳輸前後聯調

問題描述：前端資料傳輸，後端伺服器顯示錯誤 status:400

資料傳輸過程中後端傳回錯誤 400，出現 Bad request

APP 中接收資料代碼：

abc(){
uni.request({
	url: 'http://42.194.167.218:8080/publish/insertPuslish', 
	Data: {
		'userId':7,//随意，暫時寫2吧
		'image':""+this.publishData.images, //Base64格式（僅傳入一張圖檔）
		'name':""+this.publishData.name,// 傳入名稱
		'text':""+this.publishData.inputContent,//moment文字部分
		'price':this.publishData.price,//傳入定價
		'brand':""+this.publishData.name02,//傳入品牌
		'color':""+this.publishData.color,//傳入成色
		'basicClass':""+this.publishData.baseClass,//傳入基本類型
		'detailClass':""+this.publishData.detailClass ,//傳入具體類型
	},
	method: 'POST',
	dataType: 'json',
	success: (res) => {
	  console.log(this.publishData);
	  console.log(res.data);  //控制台列印這一整條資料
	  if(res.data= '插入成功'){
			uni.showToast({
				icon:'success',
				title:"釋出成功"
			}) 
	  }else{
	  	console.log("error: " + JSON.stringify(res));
	  	console.log("有問題");
	  } 
	},
});
},       
           

一開始，在調試的過程當中，以為自己的參數傳輸有問題，遇到這種情況，可以考慮直接把傳參改成對應的固定值（把參數寫死），前提是你需要跟後端的同學商量好每個參數的類型，如果改成固定值之後，如果能跑通，說明的傳參方面的問題。

如果是改成固定值之後發現還是跑不通，那說明請求本身可能還是有問題

原因分析：

找到uni-app對應的官方API文檔，檢視uni.request方法相關的資訊

https://uniapp.dcloud.io/api/request/request?id=request

uni.request({
    url: 'https://www.example.com/request', //僅為示例，并非真實接口位址。
    data: {
        text: 'uni.request'
    },
    header: {
        'custom-header': 'hello' //自定義請求頭資訊
    },
    success: (res) => {
        console.log(res.data);
        this.text = 'request success';
    }
});
           

和自己的代碼進行對比之後發現，應該将大寫的Data改為小寫的data,細節性的問題需要注意，嚴格按照示例代碼的格式來寫

總結：

通常産生問題的原因也有兩個：

1、前端傳的參數類型或者名稱與背景接收參數的實體類的屬性類型或者名稱不一緻；

2、前端送出ajax請求的資料應該是json格式字元串的，但是卻沒有将對象轉換成json格式的字元串。

3、請求格式本身有問題

4xx(請求錯誤)

這些狀态碼表示請求可能出錯，妨礙了伺服器的處理。

400(錯誤請求)伺服器不了解請求的文法。

401(未授權)請求要求身份驗證。對于登入後請求的網頁，伺服器可能傳回此響應。

403(禁止)伺服器拒絕請求。如果您在 Googlebot 嘗試抓取您網站上的有效網頁時看到此狀态碼(您可以在 Google 網站管理者工具診斷下的網絡抓取頁面上看到此資訊)，可能是您的伺服器或主機拒絕了 Googlebot 通路。

404(未找到)伺服器找不到請求的網頁。例如，對于伺服器上不存在的網頁經常會傳回此代碼。

如果您的網站上沒有 robots.txt 檔案，而您在 Google 網站管理者工具"診斷"标簽的 robots.txt 頁上看到此狀态碼，則這是正确的狀态碼。但是，如果您有 robots.txt 檔案而又看到此狀态碼，則說明您的 robots.txt 檔案可能命名錯誤或位于錯誤的位置(該檔案應當位于頂級域，名為 robots.txt)。

如果對于 Googlebot 抓取的網址看到此狀态碼(在"診斷"标簽的 HTTP 錯誤頁面上)，則表示 Googlebot 跟随的可能是另一個頁面的無效連結(是舊連結或輸入有誤的連結)。

405(方法禁用)禁用請求中指定的方法。

406(不接受)無法使用請求的内容特性響應請求的網頁。

407(需要代理授權)此狀态碼與 401(未授權)類似，但指定請求者應當授權使用代理。如果伺服器傳回此響應，還表示請求者應當使用代理。

408(請求逾時)伺服器等候請求時發生逾時。

409(沖突)伺服器在完成請求時發生沖突。伺服器必須在響應中包含有關沖突的資訊。伺服器在響應與前一個請求相沖突的 PUT 請求時可能會傳回此代碼，以及兩個請求的差異清單。

410(已删除)如果請求的資源已永久删除，伺服器就會傳回此響應。該代碼與 404(未找到)代碼類似，但在資源以前存在而現在不存在的情況下，有時會用來替代 404 代碼。如果資源已永久移動，您應使用 301 指定資源的新位置。

411(需要有效長度)伺服器不接受不含有效内容長度标頭字段的請求。

412(未滿足前提條件)伺服器未滿足請求者在請求中設定的其中一個前提條件。

413(請求實體過大)伺服器無法處理請求，因為請求實體過大，超出伺服器的處理能力。

414(請求的 URI 過長)請求的 URI(通常為網址)過長，伺服器無法處理。

415(不支援的媒體類型)請求的格式不受請求頁面的支援。

416(請求範圍不符合要求)如果頁面無法提供請求的範圍，則伺服器會傳回此狀态碼。

417(未滿足期望值)伺服器未滿足"期望"請求标頭字段的要求。