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

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

protobuf

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

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

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

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

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

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

RESTful

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

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

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

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

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

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

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

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

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

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

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

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

尽量 urlencoded，其次 json

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

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

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

@Tyanboot 存放在 request parameter

graphql

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

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