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