我正在使用 Postman Chrome 扩展程序来测试 Web 服务。
有三个选项可用于数据输入。
我猜 raw
用于发送 JSON。
另外两个 form-data
和 x-www-form-urlencoded
有什么区别?
binary
。
GraphQL
none
这些是 W3C 定义的不同表单内容类型。如果你想发送简单的文本/ASCII 数据,那么 x-www-form-urlencoded 就可以了。这是默认设置。
但是,如果您必须发送非 ASCII 文本或大型二进制数据,则表单数据就是为此。
如果您想发送纯文本或 JSON 或任何其他类型的字符串,您可以使用 Raw。顾名思义,Postman 按原样发送您的原始字符串数据,无需修改。您可以使用下拉菜单中的内容类型标头来设置您要发送的数据类型。
当您想将非文本数据附加到请求中时,可以使用二进制,例如视频/音频文件、图像或任何其他二进制数据文件。
请参阅此链接以进一步阅读:Forms in HTML documents
这解释得更好:Postman docs
请求正文 在构建请求时,您会经常处理请求正文编辑器。 Postman 允许您发送几乎任何类型的 HTTP 请求(如果您无法发送某些内容,请告诉我们!)。正文编辑器分为 4 个区域,根据正文类型具有不同的控件。 form-data multipart/form-data 是 Web 表单用于传输数据的默认编码。这模拟了在网站上填写表格并提交。表单数据编辑器允许您为数据设置键/值对(使用键值编辑器)。您也可以将文件附加到密钥。请注意,由于 HTML5 规范的限制,文件不会存储在历史记录或集合中。您必须在发送请求时再次选择文件。 urlencoded 此编码与 URL 参数中使用的编码相同。您只需要输入键/值对,Postman 就会正确地对键和值进行编码。请注意,您不能通过此编码模式上传文件。 form-data 和 urlencoded 之间可能存在一些混淆,因此请务必先检查您的 API。 raw 原始请求可以包含任何内容。除了替换环境变量外,Postman 不会触及在原始编辑器中输入的字符串。您在文本区域中输入的任何内容都会随请求一起发送。原始编辑器允许您设置格式类型以及您应该与原始正文一起发送的正确标题。您也可以手动设置 Content-Type 标头。通常,您将在此处发送 XML 或 JSON 数据。 binary 二进制数据允许您发送无法在 Postman 中输入的内容。例如,图像、音频或视频文件。您也可以发送文本文件。正如前面在表单数据部分中提到的,如果您通过历史记录或集合加载请求,则必须重新附加文件。
更新
正如 VKK 所指出的,WHATWG spec 表示 urlencoded 是表单的默认编码类型。
这些属性的无效值默认值为 application/x-www-form-urlencoded 状态。 enctype 属性的缺失值默认值也是 application/x-www-form-urlencoded 状态。
Content-Type: application/json
标头发送的 form-data(在 Postman UI 中使用键值对输入)有什么区别?和 raw 数据以 json 形式输入,例如 {foo: bar}
,具有相同的 Content-Type: application/json
标头?
以下是一些补充示例,可查看 Postman 在请求中传递的原始文本。您可以通过打开 Postman 控制台看到这一点:
https://i.stack.imgur.com/6gzgn.png
表单数据
标题
content-type: multipart/form-data; boundary=--------------------------590299136414163472038474
身体
key1=value1key2=value2
x-www-form-urlencoded
标题
Content-Type: application/x-www-form-urlencoded
身体
key1=value1&key2=value2
原始文本/纯文本
标题
Content-Type: text/plain
身体
This is some text.
原始 json
标题
Content-Type: application/json
身体
{"key1":"value1","key2":"value2"}
{"key1":"value1","key2":"value2"}
作为原始文本 发送会怎样?是否等同于使用 Raw json?我找不到说明差异的地方
Content-Type
标头将被错误命名。
多部分/表单数据
笔记。有关文件上传的更多信息,请参阅 RFC2388,包括向后兼容性问题、“multipart/form-data”与其他内容类型之间的关系、性能问题等。
有关表格安全问题的信息,请参阅附录。
内容类型“application/x-www-form-urlencoded”对于发送大量二进制数据或包含非 ASCII 字符的文本效率低下。内容类型“multipart/form-data”应用于提交包含文件、非 ASCII 数据和二进制数据的表单。
内容类型“multipart/form-data”遵循所有多部分 MIME 数据流的规则,如 RFC2045 中所述。 “multipart/form-data”的定义可在 [IANA] 注册表中找到。
“multipart/form-data”消息包含一系列部分,每个部分代表一个成功的控件。部件按照相应控件出现在文档流中的相同顺序发送到处理代理。部分边界不应出现在任何数据中;如何做到这一点超出了本规范的范围。
与所有多部分 MIME 类型一样,每个部分都有一个可选的“Content-Type”标头,默认为“text/plain”。用户代理应提供“Content-Type”标头,并附带“charset”参数。
应用程序/x-www-form-urlencoded
这是默认的内容类型。使用此内容类型提交的表单必须编码如下:
控件名称和值被转义。空格字符替换为 +', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by
%HH'、一个百分号和两个表示字符 ASCII 代码的十六进制数字。换行符表示为“CR LF”对(即,%0D%0A'). The control names/values are listed in the order they appear in the document. The name is separated from the value by
=' 和名称/值对由 `&' 相互分隔。
application/x-www-form-urlencoded
发送到服务器的 HTTP 消息的主体本质上是一个巨大的查询字符串——名称/值对由与号 (&) 分隔,名称与值由等号 (=) 分隔。这方面的一个例子是:
MyVariableOne=ValueOne&MyVariableTwo=ValueTwo
内容类型“application/x-www-form-urlencoded”对于发送大量二进制数据或包含非 ASCII 字符的文本效率低下。内容类型“multipart/form-data”应用于提交包含文件、非 ASCII 数据和二进制数据的表单。
让我们把一切都放轻松,这都是关于如何发出 http 请求的:
https://i.stack.imgur.com/AkdtY.png
http请求:
GET /getParam1 HTTP/1.1
User-Agent: PostmanRuntime/7.28.4
Accept: */*
Postman-Token: a14f1286-52ae-4871-919d-887b0e273052
Host: localhost:12345
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 55
postParam1Key=postParam1Val&postParam2Key=postParam2Val
2-生的
https://i.stack.imgur.com/v8TiJ.png
http请求:
GET /getParam1 HTTP/1.1
Content-Type: text/plain
User-Agent: PostmanRuntime/7.28.4
Accept: */*
Postman-Token: e3f7514b-3f87-4354-bcb1-cee67c306fef
Host: localhost:12345
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 73
{
postParam1Key: postParam1Val,
postParam2Key: postParam2Val
}
3-表格数据
https://i.stack.imgur.com/mR3vZ.png
http请求:
GET /getParam1 HTTP/1.1
User-Agent: PostmanRuntime/7.28.4
Accept: */*
Postman-Token: 8e2ce54b-d697-4179-b599-99e20271df90
Host: localhost:12345
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: multipart/form-data; boundary=--------------------------140760168634293019785817
Content-Length: 181
----------------------------140760168634293019785817
Content-Disposition: form-data; name="postParam1Key"
postParam1Val
----------------------------140760168634293019785817--