JSON 对象 or JSON 字符串

[secsilm]

前端向后端（ flask ）发送 AJAX POST 请求的时候，你们一般是发 JSON 对象还是 JSON 字符串呢？

同样，后端返回数据的时候是发 JSON 对象还是 JSON 字符串呢？

如果用字符串，是基于什么考虑呢？谢谢

我自己偏向于对象，双方都方便。但是同事之间讨论的时候做 Java 的坚持字符串，不知道因为啥，特来求教

[isCyan]

json 对象？难道不会被转成 x-www-form ？
python 支持 json 对象？不是要 decode json 字符串吗

[geying]

因为数据传的时候都是字符串吧

[qiayue]

后端只能返回字符串形式吧？
{"name":"V2EX"}
比如上面这个是 api 返回的，你觉得是字符串还是对象？

[keepeye]

你不妨抓个包看看....

[tao1991123]

这是对 HTTP 协议有多不了解才会问出这种问题

[nekoneko]

只会是字符串

[misaka19000]

这是来黑 python 的

[f2ck]

在 request 的时候：
我在想 json 字符串和 json 对象，到最终不还是要转化成 jsondata 放在 httpbody 里面么？
就此字符串和对象没区别。

在 response 的时候：
请求的结果是二进制吧，转化成字符串还是对象，是前端解析的事情。

[secsilm]

我不是做后端的，只是工作中涉及一点，请大家轻喷，就当给大家看个笑话，别人身攻击就行了

[secsilm]

@qiayue
@f2ck
我之所以说后端返回 json 对象（暂且这么说吧。。），是因为前端接收到我的返回后，直接可以用 a.b 的方式使用，不用任何转换，这是不是就是说返回的是 json 对象？

[kimown]

你知道 fetch 里面为什么有 tojson totext tobuffer 吗

[jackchao7432]

不是做后端的，起码也要理解什么叫对象....

[vjnjc]

你要是说的是对象和字符串都是 JSON 范畴的话，应该发对象{}，而不是字符串“”

[Chingim]

对于 json 文本，后端应该把 http 头 content-type 设置为 application/json ，一些语言或者框架看到这个头部字段，会帮你转成 json 对象

[secsilm]

谢谢各位大佬，经过提醒然后我自己查了查，发现自己接收和返回的一直是字符串，这问题简直了。。。帖子下沉。

[xiao17174]

我倒觉得还是有讨论价值的.
如果当成 json 对象,那么报文如下:
HTTP head
{"dds":2}
如果当成字符串,那么报文如下:
HTTP head
"{\"dds\":2}"
如果通信是使用成熟的框架肯定是第一种直接,Body 即 json.
但是如果考虑到通用性,其实第二种也有存在的价值.原因在于它被首先认为是一个字符串,这样即使在不支持 json 解析的系统中也被看成是一个整体.

[sunnyadamm]

当然字符串啊。哈哈哈哈

[Shynoob]

JSON 格式的字符串

[reus]

json 就是用字符串表示 js 对象，你概念混乱。

[Chingim]

@xiao17174 http 报文主体的内容是字节，没什么对象 /文本 /图像的概念。至于这些字节什么含义怎么解析，通过报文头部字段告诉另一端就好了。你举的这个例子，不管 content-type 是 application/json 还是 plain/text，报文主体的内容是一样的字节

[xiao17174]

@Chingim 应该是被成熟框架养得娇嫩的程序员吧.笑~.考虑一种情况.body 中不只是 json 或者不止一个 json 呢?
这么和你讲好了.我们可以把数据大概的看成三个层次:
1.最底层.一切皆是二进制.
2.中间层,数据都是 int/double/string/bool 等.
3.最上层,数据是 json/http/h264/mp3.
永远是越下层越通用.所以把 json 重新包装成 string,是把它通用化了.
当然,有一个概念不要混淆,json 以 string 作载体.这是协议规定的.也就是说,序列化后的 json 肯定是一个 string 即字符串.这个时候再做一次包装是 string(string).
做这个操作其实是很丑陋的.完全不建议这样用.
(可以用更好的办法规避它.比如永远保证一个 body 即是一个 json,json 里放 json 就可以了) 然而这就不在我们的讨论范围了.

[Chingim]

@xiao17174

1. 讨论问题请不要倚老卖老，还有谢谢你夸我嫩。
2. 我的意思是你想把数据当成纯文本传输，让另一端想怎么解析就怎么解析(你所谓的更通用)，这完全可以，把 content-type 设置成 plain/text 就 ok 了。而不需要再包一层两层，把 {"dds":2} 变成 "{\"dds\":2}" ，因为前者已经是纯文本了。

[xiao17174]

@Chingim
1.你理解成我是倚老卖老也算是一种新的思路.我的本意是说你幼稚.
2.首先不是什么语言都有框架让你去认 content-type 的.裸解析 tcp 了解一下(我至少用两种语言做过这种事,因为它没有成熟的框架).其次,我已经说了假设了,假如一个 c 系程序员野蛮的把两个 json 拼接到一个 body 里.content-type 设成 text.现在要分别解析出两个 json 对象,那么这个最外层的引号就成为了一种分界标志.所以 string(string)+string(string)之后是一个 string,但是可以反解析出两个子 string.但是单纯的 string+string 是会完全合并成一个 string,不可逆的.
3.我再次强调这只是理论上的价值,有无数的理由让我们不要这样做.
4.你显然没有理解我上个回复中强调的内容.不要混淆 json 本身是个 string,即纯文本的本质.