
前端向后端( flask )发送 AJAX POST 请求的时候,你们一般是发 JSON 对象还是 JSON 字符串呢?
同样,后端返回数据的时候是发 JSON 对象还是 JSON 字符串呢?
如果用字符串,是基于什么考虑呢?谢谢
我自己偏向于对象,双方都方便。但是同事之间讨论的时候做 Java 的坚持字符串,不知道因为啥,特来求教
1 isCyan 2018 年 12 月 4 日 via Android json 对象?难道不会被转成 x-www-form ? python 支持 json 对象?不是要 decode json 字符串吗 |
2 geying 2018 年 12 月 4 日 因为数据传的时候都是字符串吧 |
3 qiayue PRO 后端只能返回字符串形式吧? {"name":"V2EX"} 比如上面这个是 api 返回的,你觉得是字符串还是对象? |
4 keepeye 2018 年 12 月 4 日 你不妨抓个包看看.... |
5 tao1991123 2018 年 12 月 4 日 这是对 HTTP 协议有多不了解才会问出这种问题 |
6 nekoneko 2018 年 12 月 4 日 只会是字符串 |
7 misaka19000 2018 年 12 月 4 日 via Android 这是来黑 python 的 |
8 f2ck 2018 年 12 月 4 日 在 request 的时候: 我在想 json 字符串和 json 对象,到最终不还是要转化成 jsondata 放在 httpbody 里面么? 就此字符串和对象没区别。 在 response 的时候: 请求的结果是二进制吧,转化成字符串还是对象,是前端解析的事情。 |
9 secsilm OP 我不是做后端的,只是工作中涉及一点,请大家轻喷,就当给大家看个笑话,别人身攻击就行了 |
10 secsilm OP |
11 kimown 2018 年 12 月 4 日 via Android 你知道 fetch 里面为什么有 tojson totext tobuffer 吗 |
12 jackchao7432 2018 年 12 月 4 日 不是做后端的,起码也要理解什么叫对象.... |
13 vjnjc 2018 年 12 月 4 日 via Android 你要是说的是对象和字符串都是 JSON 范畴的话,应该发对象{},而不是字符串“” |
14 Chingim 2018 年 12 月 4 日 via Android 对于 json 文本,后端应该把 http 头 content-type 设置为 application/json ,一些语言或者框架看到这个头部字段,会帮你转成 json 对象 |
15 secsilm OP 谢谢各位大佬,经过提醒然后我自己查了查,发现自己接收和返回的一直是字符串,这问题简直了。。。帖子下沉。 |
16 xiao17174 2018 年 12 月 4 日 我倒觉得还是有讨论价值的. 如果当成 json 对象,那么报文如下: HTTP head {"dds":2} 如果当成字符串,那么报文如下: HTTP head "{\"dds\":2}" 如果通信是使用成熟的框架肯定是第一种直接,Body 即 json. 但是如果考虑到通用性,其实第二种也有存在的价值.原因在于它被首先认为是一个字符串,这样即使在不支持 json 解析的系统中也被看成是一个整体. |
17 sunnyadamm 2018 年 12 月 4 日 当然字符串啊。哈哈哈哈 |
18 Shynoob 2018 年 12 月 4 日 JSON 格式的字符串 |
json 就是用字符串表示 js 对象,你概念混乱。 |
20 Chingim 2018 年 12 月 4 日 via Android @xiao17174 http 报文主体的内容是字节,没什么对象 /文本 /图像的概念。至于这些字节什么含义怎么解析,通过报文头部字段告诉另一端就好了。你举的这个例子,不管 content-type 是 application/json 还是 plain/text,报文主体的内容是一样的字节 |
21 xiao17174 2018 年 12 月 4 日 @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 就可以了) 然而这就不在我们的讨论范围了. |
22 Chingim 2018 年 12 月 4 日 via Android @xiao17174 1. 讨论问题请不要倚老卖老,还有谢谢你夸我嫩。 2. 我的意思是你想把数据当成纯文本传输,让另一端想怎么解析就怎么解析(你所谓的更通用),这完全可以,把 content-type 设置成 plain/text 就 ok 了。而不需要再包一层两层,把 {"dds":2} 变成 "{\"dds\":2}" ,因为前者已经是纯文本了。 |
23 xiao17174 2018 年 12 月 5 日 @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,即纯文本的本质. |