亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

前后端聯(lián)調(diào)之Form Data與Request Payload,你真的了解嗎?

Fundebug / 3212人閱讀

摘要:前言做過(guò)前后端聯(lián)調(diào)的小伙伴,可能有時(shí)會(huì)遇到一些問(wèn)題。它是請(qǐng)求中空行的后面那部分。這就是它向你展示的。值得形式是以的形式提交的。傳遞對(duì)象的時(shí)候,默認(rèn)為類型的值,與非時(shí),的區(qū)別。如果是字符串的話,后端解析的內(nèi)容時(shí)候,肯定要去解析啦。

前言

做過(guò)前后端聯(lián)調(diào)的小伙伴,可能有時(shí)會(huì)遇到一些問(wèn)題。例如,我明明傳遞數(shù)據(jù)給后端了,后端為什么說(shuō)沒(méi)收到呢?這時(shí)候可能就會(huì)就會(huì)有小伙伴陷入迷茫,本文從chrome-dev-tools(F12調(diào)試器)中看到的FormDataRequestBody,給小伙伴們提供一種可能的思路。也給小伙伴們提供一些問(wèn)題的探究方法。

簡(jiǎn)介

什么是FormData?什么是RequestPayload?不解釋,直接上圖:

區(qū)別?

因?yàn)檫@里觸及了我的知識(shí)盲區(qū),所以有了本文。這個(gè)答案是我在stackoverflow上得到的。首先還是貼問(wèn)題,貼答案。

What"s the difference between “Request Payload” vs “Form Data” as seen in Chrome dev tools Network tab。
中文翻譯:chrome開發(fā)者工具中的Request Payload與Form Data有什么區(qū)別?

高票回答:

The Request Payload - or to be more precise: payload body of a HTTP Request - is the data normally send by a POST or PUT Request. It"s the part after the headers and the CRLF of a HTTP Request.

A request with Content-Type: application/json may look like this:

POST /some-path HTTP/1.1
Content-Type: application/json

{ "foo" : "bar", "name" : "John" }

If you submit this per AJAX the browser simply shows you what it is submitting as payload body. That’s all it can do because it has no idea where the data is coming from.

If you submit a HTML-Form with method="POST" and Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data your request may look like this:

POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded

foo=bar&name=John

In this case the form-data is the request payload. Here the Browser knows more: it knows that bar is the value of the input-field foo of the submitted form. And that’s what it is showing to you.

So, they differ in the Content-Type but not in the way data is submitted. In both cases the data is in the message-body. And Chrome distinguishes how the data is presented to you in the Developer Tools.

翻譯過(guò)來(lái)是說(shuō):
Request Payload更準(zhǔn)確的說(shuō)是http request的payload body。一般用在數(shù)據(jù)通過(guò)POST請(qǐng)求或者PUT請(qǐng)求。它是HTTP請(qǐng)求中空行的后面那部分。(PS:這里涉及一個(gè)http常被問(wèn)到的問(wèn)題,http請(qǐng)求由哪幾部分組成,一般是請(qǐng)求行,請(qǐng)求頭,空行,請(qǐng)求體。payload body應(yīng)該是對(duì)應(yīng)請(qǐng)求體。)

一個(gè)請(qǐng)求伴隨著header設(shè)置為Content-Type: application/json時(shí)候,看起來(lái)可能像這樣:

POST /some-path HTTP/1.1
Content-Type: application/json

{ "foo" : "bar", "name" : "John" }

如果你正常請(qǐng)求一個(gè)ajax。瀏覽器會(huì)簡(jiǎn)單的將你提交的內(nèi)容作為payload展示出來(lái),這就是它所能做的,因?yàn)樗恢罃?shù)據(jù)來(lái)自哪里。

如果你提交了一個(gè)html表單并且配置上了method="post",并且設(shè)置了Content-Type: application/x-www-form-urlencoded或者Content-Type: multipart/form-data。那么你的請(qǐng)求可能長(zhǎng)這個(gè)樣:

POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded

foo=bar&name=John

這里的form-data就是request payload。在這里,瀏覽器知道更多:它知道bar是提交表單的輸入字段foo的值。這就是它向你展示的。

所以區(qū)別就是,他們只是因?yàn)?b>Content-Type設(shè)置的不同,并不是數(shù)據(jù)提交方式的不同,這兩種提交都會(huì)將數(shù)據(jù)放在message-body中。但是chrome瀏覽器的開發(fā)者工具會(huì)根據(jù)這個(gè)ContentType區(qū)分顯示方式。

細(xì)節(jié)

好了,到這里我們知道了,其實(shí)都是放到了payload中。那么具體有什么區(qū)別呢?為什么有時(shí)候后端拿不到值呢?這就不得不說(shuō)對(duì)payload的解析方式了。我們以幾個(gè)chrome下的測(cè)試案例,來(lái)理一理這個(gè)邏輯。

傳統(tǒng)的Form表單提交 場(chǎng)景構(gòu)造

如果我這里點(diǎn)擊提交按鈕,就會(huì)觸發(fā)瀏覽器的提交功能,那結(jié)果是什么樣呢?

注意點(diǎn)

可以看到Content-Typeapplication/x-www-form-urlencoded
值得形式是以key1=value1&key2=value2的形式提交的。

傳統(tǒng)的ajax提交 場(chǎng)景構(gòu)造
function submit2() {
    var xhr = new XMLHttpRequest();
    xhr.timeout = 3000;
    var obj = {a: 1, b: 2};
    xhr.open("POST", "/");
    xhr.send(obj);
}

首先我們構(gòu)造一個(gè)簡(jiǎn)單的函數(shù),然后觸發(fā)它。通過(guò)chrome反饋來(lái)看:

注意點(diǎn)

1.默認(rèn)的Content-Typetext/plain。
2.Request Payload會(huì)對(duì)非字符串做字符串轉(zhuǎn)換。
3.通過(guò)xhr.send(JSON.stringify(obj));可修正要發(fā)的內(nèi)容

axios方式提交 場(chǎng)景構(gòu)造

由于axios已經(jīng)是vue、react的準(zhǔn)標(biāo)配請(qǐng)求方式了,所以這里探究一下它。
首先我門看axios的文檔,當(dāng)post提交時(shí)候可以傳遞什么類型參數(shù):

注意這個(gè)類型,我們分別構(gòu)造兩個(gè)場(chǎng)景。對(duì)應(yīng)它。

function submit3() {
    var sence1 = "name=123&val=456";
    var sence2 = {name: 123, val: 456};
    axios.post("/", sence1)
}

分別傳遞字符串與對(duì)象,提交post請(qǐng)求,然后觀察結(jié)果:

場(chǎng)景1——傳遞字符串時(shí)候的結(jié)果:

場(chǎng)景2——傳遞對(duì)象的結(jié)果:

注意點(diǎn)

1.當(dāng)我們傳遞字符串的時(shí)候,Content-Type自動(dòng)轉(zhuǎn)為xxx-form-xxx的形式。當(dāng)為對(duì)象的時(shí)候,自動(dòng)轉(zhuǎn)化為xxx/json。
2.字符串的時(shí)候以key1=val1&key2=val2的形式體現(xiàn),對(duì)象以JSON字符串形式體現(xiàn)。

總結(jié)

探索了這么多種情況之后,那么我們回顧一下:

Content-Type的差異

1.傳統(tǒng)的ajax請(qǐng)求時(shí)候,Content-Type默認(rèn)為"文本"類型。
2.傳統(tǒng)的form提交的時(shí)候,Content-Type默認(rèn)為"Form"類型。
3.axios傳遞字符串的時(shí)候,Content-Type默認(rèn)為"Form"類型。
4.axios傳遞對(duì)象的時(shí)候,Content-Type默認(rèn)為"JSON"類型

Content-Type的值,F(xiàn)orm與非Form時(shí),payload的區(qū)別。

1.都只支持字符串類型(以上探究的幾種情況)
2.Form需要傳遞的格式為key1=value1&key2=value2,類似GET請(qǐng)求的QueryString格式
3.非Form一般為JSON.stringify(formDataObject)形式

后端取不到值?

無(wú)論何種形式傳遞,后端解析表單信息的時(shí)候,會(huì)考慮Content-Type。如果是JSON字符串的話,后端解析payload的內(nèi)容時(shí)候,肯定要去解析JSON啦。如果是key1=value1&key2=value2的形式,則需要去分割字符串。

當(dāng)然這些事情一般后端使用的框架會(huì)去處理,但是框架給后端提供取值接口有可能是不同的,所以前端的小伙伴在處理請(qǐng)求問(wèn)題時(shí),一定要跟后端小伙伴商量好,是用JSON還是FormData哈。

后記

本來(lái)只是小小的一個(gè)問(wèn)題,仔細(xì)研究起來(lái)發(fā)現(xiàn)挺多細(xì)節(jié)。今天就花時(shí)間整理了一下,希望能給大家一些幫助。碼字不容易,如果感到這篇文章對(duì)你有用。點(diǎn)個(gè)贊,收個(gè)藏唄。

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://www.ezyhdfw.cn/yun/103261.html

相關(guān)文章

  • Dva + Ant Design 前后分離 React 應(yīng)用實(shí)踐

    摘要:數(shù)據(jù)緩存對(duì)于一個(gè)應(yīng)用來(lái)說(shuō),緩存是很重要的一步。所以,比較常見(jiàn)的方法就是將數(shù)據(jù)緩存在中。什么時(shí)候做數(shù)據(jù)緩存例用戶信息緩存參見(jiàn)在中配置了檢測(cè)中的是否存在。 源站鏈接 https://tkvern.com 繼 Rails 從入門到完全放棄 擁抱 Elixir + Phoenix + React + Redux 這篇文章被噴之后,筆者很長(zhǎng)一段時(shí)候沒(méi)有上社區(qū)逛了?,F(xiàn)在 tkvern 又回歸了,給...

    tainzhi 評(píng)論0 收藏0
  • 一個(gè)HTTP打趴80%面試者

    摘要:閱讀原文一個(gè)打趴面試者面試一年多,每當(dāng)我問(wèn)起面試者對(duì)的了解時(shí),個(gè)個(gè)回答令我瞠目結(jié)舌,這些開發(fā)者都有年的經(jīng)驗(yàn)。向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求例如提交表單或者上傳文件。 閱讀原文:一個(gè)HTTP打趴80%面試者 面試一年多,每當(dāng)我問(wèn)起面試者對(duì)HTTP的了解時(shí),個(gè)個(gè)回答令我瞠目結(jié)舌,這些開發(fā)者都有3-5年的經(jīng)驗(yàn)。請(qǐng)不要讓我叫你野生程序員,是時(shí)候了解HTTP了,讓我們當(dāng)個(gè)正規(guī)軍。 起因 面試官:...

    econi 評(píng)論0 收藏0
  • ajax入門

    摘要:基于標(biāo)準(zhǔn)被廣泛支持。這樣的類最初是在中作為一個(gè)名為的對(duì)象引入的。請(qǐng)求還沒(méi)有被發(fā)送。當(dāng)為,這個(gè)屬性返回目前已經(jīng)接收的響應(yīng)部分。由服務(wù)器返回的狀態(tài)代碼,如表示成功,而表示錯(cuò)誤。方法取消當(dāng)前響應(yīng),關(guān)閉連接并且結(jié)束任何未決的網(wǎng)絡(luò)活動(dòng)。 前言 總括: 本文講解了ajax的歷史,工作原理以及優(yōu)缺點(diǎn),對(duì)XMLHttpRequest對(duì)象進(jìn)行了詳細(xì)的講解,并使用原生js實(shí)現(xiàn)了一個(gè)ajax對(duì)象以方便日常開...

    Fundebug 評(píng)論0 收藏0
  • 跨域問(wèn)題匯總

    摘要:因?yàn)闉g覽器的同源策略,前端開發(fā)會(huì)遇到各種跨域問(wèn)題。前言在總結(jié)各種跨域問(wèn)題之前,我們先來(lái)了解一下瀏覽器的同源策略。所以只能解決一級(jí)域名相同二級(jí)域名不同的跨域問(wèn)題。 跨域問(wèn)題的場(chǎng)景和解決方案多種多樣,只要是做前端開發(fā),總會(huì)遇到。而且面試時(shí)也是必問(wèn)的問(wèn)題。所以自己學(xué)習(xí)總結(jié)記錄一下。 因?yàn)闉g覽器的同源策略,前端開發(fā)會(huì)遇到各種跨域問(wèn)題。本篇文章總結(jié)了遇到跨域問(wèn)題的不同的場(chǎng)景以及對(duì)應(yīng)的解決方案。 ...

    MkkHou 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<