前台向后台传参到底序列化还是 json

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2462 天前的主题，其中的信息可能已经有所发展或是发生改变。

传参简单数据的序列化，复杂的数据 json ？
还是全部 json ？
到底哪种好呢？

JSON

传参

序列化

前台

26 条回复 • 2018-02-22 10:15:43 +08:00

Event

2018-02-20 22:02:46 +08:00

一般都是序列化了吧已经足够了
复杂数据单独 json 也行没必要全局 json

lty1993

2018-02-20 22:04:07 +08:00

protobuf

blless

2018-02-20 22:32:34 +08:00 via Android

json 也是序列化只不过是一种明文格式

j2gg

2018-02-21 02:01:22 +08:00

json 也是你说的序列化的一种，可以参考下 thrift 的 protocol。
哪种好，看具体情况，权衡利弊。json 灵活但是容易失控，thirft/protobuf 明晰但频繁改数据定义的话，比较累

qiyuey

2018-02-21 08:02:21 +08:00 via Android

前端 Node 和后端交互，可以考虑走 4 层 RPC 调用，而不是 HTTP

azh7138m

2018-02-21 09:02:32 +08:00 via Android

@qiyuey HTTP RPC 也不少，TCP 是为了啥

leslie000666

2018-02-21 09:16:27 +08:00 via Android

建议 json 吧，不管是什么，其实对于传输来说应该都是字符串，只是客户端是浏览器进行了解包（按照一定规则），后端框架进行了封包（按照一定规则）

MeteorCat

2018-02-21 09:23:39 +08:00 via Android

Json，自带有 Json 编码解码，其他的方法？你让前端来自己做协议编码解码？不是开玩笑吗？

sunwei0325

2018-02-21 09:29:19 +08:00

一般都是前端说了算这个, 你弄的太复杂太效率, 最后前端告诉你, 解析不了, 我就用 json, 你白忙活

Enochyun

2018-02-21 09:38:48 +08:00 via iPhone

RESTful

jorneyr

2018-02-21 09:40:14 +08:00

建议尽量序列化，应该是指 JSON.stringify(jsonObject) 的方式，最后是以 form 表单提交，后端方便 XSS 防御，例如 Servlet 里使用 Filter，如果传 JSON 的话，数据存储在 request body 里，处理 XSS 攻击就比较麻烦。对于复杂数据，只好用纯 JSON 的格式了。

qiyuey

2018-02-21 11:23:57 +08:00 via Android

@azh7138m 主要是效率，HTTP 有很多不必要调用，DNS 等等，量大了的话，对网络的压力很大

DOLLOR

2018-02-21 11:37:50 +08:00 via Android

看你的后端语言是什么，如果是 JS，那么 JSON 当然是很好的选择。

mengzhuo

2018-02-21 11:49:26 +08:00 via iPhone

@qiyuey 也看业务需求，如果是调用方可控或者后端，用啥都好。

调用方不可控或者要对 web，前端乖乖上 jsonrpc 或者 restful。

DNS 几乎可以忽略不计……除非 Timeout 太短。
HTTP 也就多点头，上 gzip，HTTP2 就更少了。
缺点楼上说了些，其实优点也不少。

容易做 7 层负载均衡，升级不间断
标准支持好，各个语言，调用方容易实现
监控链路，旁路容易
还有衍生 4 层实现满足不少变态需求

其实业务的请求量一般达不到这么高要求，随便一台 48 核双路万兆就能顶住全部前端压力了╮(￣▽￣"")╭
倒是后面监控的压力会大很多，特别秒级监控……算了……不说了

qiyuey

2018-02-21 12:01:47 +08:00 via Android

@mengzhuo 量大了，DNS 就不能忽略不计了。。。

mhycy

2018-02-21 13:05:57 +08:00

统一封装成 JSON 数据传递，统一接口
优势在于结构清晰数据入口统一
如果是 form 传递，需要面对编码问题
JSON 是标准的 UTF-8 编码，但 FORM 传递时候并不一定

mengzhuo

2018-02-21 13:27:51 +08:00 via iPhone

@qiyuey
不知道你架构为啥会依赖 DNS 即时查询
我们内部服务 DNS 查询，一分钟 timeout，还有各级缓存顶着，没见过成为瓶颈……

qiyuey

2018-02-21 14:26:55 +08:00 via Android

@mengzhuo DNS 4 层负载 nginx，这三步下来，对交换机都是考验

wizardforcel

2018-02-21 14:49:24 +08:00 via Android

尽量 urlencoded，其次 json

Equim

2018-02-21 16:02:26 +08:00

JSON 本身不就是一种序列化吗？

如果是 Web 的话，还是比较推荐 JSON，毕竟原生支持，也容易调试。如果是后端 RPC 的话还是推荐用 msgpack 或 protobuf 之类的。

Tyanboot

2018-02-21 16:19:59 +08:00 via Android

@jorneyr form 表单传数据，不也是存在 request body ？

jorneyr

2018-02-21 16:36:08 +08:00

@Tyanboot 存放在 request parameter

xu33

2018-02-21 16:58:47 +08:00

graphql

Tyanboot

2018-02-21 18:04:37 +08:00

@jorneyr 这是 spring 的说法吧. 换了其他框架就没这说法了. RFC 里面都统称为 Entity Body, 也就是 request body, 没有 request parameter 的说法.

jorneyr

2018-02-22 10:15:43 +08:00

@Tyanboot 是的，SpringMVC 是一种实现，也可以用 PHP 读取下 form 表单提交和 application/json 提交的数据，是从不同的存储中读取的。
RFC 里面都统称为 Entity Body，统称没问题，框架可以提供统一的读取接口对调用者屏蔽底层读取逻辑，但不代表他们是同一个东西。