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



还没有评论,来说两句吧...