请求方式除了json还有什么

除了JSON，这些请求方式你都知道吗？

在Web开发的世界里,JSON（JavaScript Object Notation）几乎成了前后端数据交换的“代名词”，它轻量、易读、易于机器解析，被RESTful API、前后端分离项目广泛使用，但你是否想过，除了JSON，还有哪些请求方式能承载我们的数据？从Web诞生之初，各种请求方式就一直在演进，它们在不同场景下各有优势，我们就来盘点一下那些“非JSON”的请求方式，看看它们的特点与应用场景。

表单数据（application/x-www-form-urlencoded）：传统Web的“老朋友”

提到非JSON的请求方式,最经典的莫过于application/x-www-form-urlencoded，这是HTML表单默认的提交格式，也是Web早期最常用的数据传输方式之一。

特点

• 格式简单：数据以key=value的形式存在，多个键值对用&连接，如name=张三&age=25&city=北京。
• 自动编码：特殊字符（如空格、&、）会被转义为加十六进制编码（如空格变为%20），避免解析错误。
• 兼容性好：所有浏览器和服务器都原生支持，无需额外配置。

应用场景

• 传统网页的表单提交（如登录、注册页面的用户名密码传递）。
• 需要兼容老旧系统或浏览器的场景（如某些企业内部的OA系统）。
• 简单的键值数据传输,尤其是数据量不大、无需嵌套结构的情况。

示例

一个典型的登录表单,提交后请求体可能是：
username=admin&password=123456&remember=true

multipart/form-data：文件上传的“专属通道”

如果你开发过支持文件上传的功能（如头像上传、附件提交），一定对multipart/form-data不陌生，它是HTML表单中enctype="multipart/form-data"时使用的格式，专为处理二进制数据和混合数据（文本+文件）设计。

特点

• 支持二进制数据：可以传输文件（如图片、视频、PDF等），这是其他文本格式无法做到的。
• 混合数据传输：既能提交文本字段（如表单中的“文件描述”），也能上传文件，两者通过boundary（分隔符）区分。
• 数据量较大：相比x-www-form-urlencoded，multipart/form-data会产生更多的额外数据（如分隔符、头部信息），因此不适合传输大量纯文本数据。

应用场景

• 文件上传（用户头像、商品图片、附件等）。
• 需要同时提交文本和二进制数据的表单（如“上传简历+填写个人信息”）。

示例

上传一张图片时,请求体可能类似：

------WebKitFormBoundary7MA4YWxkTrZu0gW  
Content-Disposition: form-data; name="file"; filename="example.jpg"  
Content-Type: image/jpeg  
[二进制图片数据]  
------WebKitFormBoundary7MA4YWxkTrZu0gW  
Content-Disposition: form-data; name="description"  
这是一张示例图片  
------WebKitFormBoundary7MA4YWxkTrZu0gW--  

纯文本（text/plain)：简单到“极致”的传输

text/plain是一种非常“朴素”的请求方式，顾名思义，它只传输纯文本数据，没有任何格式限制（如键值对、嵌套结构）。

特点

• 无格式约束：数据就是一段原始文本，服务器需按约定解析（如按行分割、按特定分隔符拆分）。
• 可读性强：人可以直接阅读，适合传递简单的文本信息（如日志、备注）。
• 使用场景少：由于缺乏结构化能力，实际开发中较少用于复杂数据传输，多见于特定工具或内部接口。

应用场景

• 传递简单的文本指令（如某些内部API的调试接口）。
• 日志数据上报（如将客户端日志以纯文本格式发送到服务器）。 留言板等无需结构化处理的文本内容。

示例

请求体可能是一段简单的文本：
这是一段纯文本数据，没有键值对，也没有特殊格式。

XML（application/xml)：曾经的“数据交换霸主”

在JSON普及之前,XML（eXtensible Markup Language）是Web数据交换的绝对主角，它通过标签和嵌套结构描述数据，具有严格的语法规则和可扩展性。

特点

• 结构化强：通过标签嵌套表达复杂数据关系（如用户信息的嵌套结构）。
• 可读性较好：人类可读，且支持注释（方便调试和维护）。
• 冗余度高：标签名重复出现，导致数据体积较大（如<user><name>张三</name><age>25</age></user>）。
• 解析复杂：相比JSON，XML的解析（尤其是JavaScript中）更繁琐，需要DOM或SAX解析器。

应用场景

• 企业级应用（如银行、政务系统）的接口，部分传统系统仍在使用。
• 需要严格数据格式约束的场景（如配置文件、文档数据）。
• 跨平台数据交换（如不同语言/系统间的通信，XML是通用标准）。

示例

一个用户信息的XML请求体：

<?xml version="1.0" encoding="UTF-8"?>  
<user>  
    <name>张三</name>  
    <age>25</age>  
    <city>北京</city>  
    <hobbies>  
        <hobby>阅读</hobby>  
        <hobby>游泳</hobby>  
    </hobbies>  
</user>  

Protobuf（application/x-protobuf)：高性能的“二进制替代者”

当数据传输效率成为关键时,二进制格式会进入视野，Protobuf（Protocol Buffers）是Google开发的一种二进制序列化格式，相比JSON和XML，它更小、更快、更高效。

特点

• 体积小：二进制编码，没有冗余的标签和空格，数据体积通常只有JSON的1/3到1/10。
• 解析快：二进制格式无需解析文本，直接按预定义的结构反序列化，速度远快于JSON/XML。
• 强类型支持：需提前定义.proto文件（数据结构），编译后生成对应语言的代码，避免运行时类型错误。
• 跨语言支持：支持Java、Python、Go、C++等多种语言，适合跨语言服务通信。

应用场景

• 高性能API（如实时通信、游戏服务器、微服务间调用）。
• 移动端数据传输（减少流量消耗，提升加载速度）。
• 大规模数据存储与传输（如日志分析、时序数据库）。

示例

假设定义.proto文件：

message User {  
    string name = 1;  
    int32 age = 2;  
    string city = 3;  
}  

传输的数据是二进制格式,无法直接阅读，但解析后可得到与JSON/XML相同的数据结构。

其他格式：从CSV到MessagePack的“多样性”

除了上述主流格式,还有一些小众但实用的请求方式：

CSV（text/csv）

用逗号分隔值的文本格式,适合表格型数据（如Excel导出/导入），常用于数据分析、报表生成等场景，
name,age,city
张三,25,北京
李四,30,上海

MessagePack（application/x-msgpack）

JSON的二进制替代版,兼容JSON数据结构，但体积更小、解析更快，适合对性能和体积有双重需求的场景。

YAML（application/x-yaml）

可读性比JSON更强的标记语言,支持注释和复杂数据结构，常用于配置文件（如Docker Compose、Kubernetes配置）。

没有“最好”，只有“最合适”

回到最初的问题：“请求方式除了JSON还有什么？”答案是：很多，且各有适用场景。

• 如果追求简单兼容,x-www-form-urlencoded和multipart/form-data是传统Web的可靠选择；
• 如果需要传输文件,multipart/form-data无可替代；
• 如果面对企业级或遗留系统,XML可能仍在使用；
• 如果追求高性能,Protobuf、MessagePack等二进制格式能大幅提升效率；
• 如果只是传递简单文本,text/plain足够轻量。

JSON的流行并非因为它“全能”，而是因为它在“可读性”“轻量性”“解析效率”之间取得了平衡，但在实际开发中，我们应根据数据类型、性能需求、兼容性要求等因素，灵活选择最合适的请求方式——毕竟，