HTTP 请求数据格式详解

这些名词都代表了在网络传输（尤其是 HTTP 请求）中，客户端向服务端发送数据时所采用的数据格式（编码方式）。它们通常通过 HTTP 请求头中的 Content-Type 来标识。

为了方便理解，我们可以将它们分为四大类：传统表单、现代 API、专用查询语言、以及底层与二进制格式。

第一类：传统 Web 表单格式

这类格式诞生于 Web 早期，主要服务于浏览器原生的 <form> 表单提交。

1. x-www-form-urlencoded (application/x-www-form-urlencoded)

• 这是什么：最原始、最常见的表单提交默认格式。
• 长什么样：键值对被拼接成类似 URL 参数的样子。空格会变成 +，特殊字符会被转化为 %XX（URL 编码）。
  • 示例：name=John+Doe&age=25&city=New%20York
• 适用场景：提交简单的、纯文本的短表单（如登录、搜索）。
• 缺点：无法上传文件，嵌套复杂的结构化数据（如数组、对象）非常麻烦。

2. form-data (multipart/form-data)

• 这是什么：为了解决 x-www-urlencoded 无法传文件而发明的格式。它将数据分成多个“部分（parts）”，每个部分用一个随机生成的“边界（boundary）”隔开。
• 长什么样：
• 适用场景：包含文件上传的场景，或者文件与文本数据混合提交的场景。

第二类：现代 API 文本结构化格式

这类格式主要用于系统间通信、前后端分离的 API 交互。

3. JSON (application/json)

• 这是什么：JavaScript Object Notation。目前互联网最绝对的主流数据交换格式。
• 长什么样：键值对组成的树状结构，极度清晰。
• 适用场景：99% 的现代 RESTful API（前端与后端交互、微服务间通信）。
• 优点：人类可读性强，大多数编程语言都有原生解析库，体积适中。

4. XML (application/xml 或 text/xml)

• 这是什么：可扩展标记语言，JSON 流行之前的“老大哥”。
• 长什么样：类似 HTML 的标签对。
• 适用场景：老旧的企事业系统（如银行、医院系统）、SOAP 协议 API、微信支付等部分传统接口。
• 缺点：语法冗余，标签占用的字符数甚至比数据本身还多（体积大），解析相对复杂。

第三类：专用查询语言

5. GraphQL (application/graphql 或包装在 application/json 中)

• 这是什么：Facebook 发明的一种数据查询语言。它不是单纯的数据承载格式，而是一种“按需索取”的语法。
• 长什么样：客户端发送特定的查询语句，服务端只返回要求的数据。
• 适用场景：多端复用 API、对流量极其敏感的移动端（按需获取字段，避免多余数据，解决 REST API 过度获取或获取不足的问题）。

第四类：底层、原始与高性能格式

6. Text (text/plain)

• 这是什么：纯文本。没有任何结构或解析规则。
• 长什么样：Hello world, this is just text.
• 适用场景：发送极其简单的指令，或者服务端直接返回一段供人阅读的文本（很少用于复杂的接口交互）。

7. Binary (application/octet-stream 或其他具体的如 image/jpeg)

• 这是什么：纯粹的二进制字节流（0和1的组合）。
• 长什么样：在文本编辑器里看是一堆乱码。
• 适用场景：直接上传或下载裸文件（视频、音频、图片）。比如你直接向服务端推流一段音频数据。

8. MsgPack (application/msgpack)

• 这是什么：可以理解为 “压缩版的二进制 JSON”。它在 JSON 的数据结构基础上，去掉了冒号、括号、引号等，转成了极其紧凑的二进制格式。
• 适用场景：对性能、带宽和延迟要求极其苛刻的场景（如高频交易、大型多人在线游戏、IoT 物联网设备通信）。
• 优点/缺点：比 JSON 体积更小、解析更快；但肉眼无法直接阅读，调试比较麻烦。

总结对比速查表