Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

QueryString 与 JSON

  QueryString 的传输都是字符串,并没有自带的类型机制。服务器在接收并处理 QueryString 的时候总是要考虑很多情况,比如一个数值类型要考虑空字符串到底应该怎么解析,布尔型也会担心被传一些奇奇怪怪的东西过来(PHP 将字符串的 0 视为 false),那么我们为何不使用 JSON 呢?
  确实在一些程序中我尝试使用过将 JSON 字符串直接放到问号后面传输,虽然理论上可以这么玩,但是在实际使用时是会有点不方便。比如调试时浏览器控制台会显示一坨奇奇怪怪的东西,而不是一个个参数的键值对。如果是表单提交,默认的 FORM 元素很难构造出这样一个完全是 JSON 的 QueryString。
  既然如此我们为什么非要走极端路线呢?部分 JSON 不就好了么?QueryString 本来是一层的参数列表(虽然 PHP 的那套规则可以结构化,但最终的传输还是一层的),我们只要保持这一层参数列表,只对值使用 JSON 不就可以解决这个问题么?而且甚至不需要对所有 value 使用 JSON,只要对部分真正具有类型需求的数据,在接口定义时将类型定义为 JSON 下的某个类型(Null、Number、String、Boolean、Array、Object)即可。
  其它没有类型需求的,比如字符串常量之类的东西就可以直接传输不走 JSON。实际上 JSON 对数值和布尔类型的处理只是简单地字符串化,不会增加额外的传输数据量。只有字符串才会在头尾加上双引号,中间加上转义。如果 API 定义时已知某些字段不使用 JSON,那就连字符串化的开销都可以避免。
  在对值时候 JSON 之类,服务器对某个字段的值做 JSON 解析失败就可以直接响应 400,告诉客户端某个字段的类型错误,这才是正确的逻辑。
  最后,对值使用 JSON 还顺带解决了结构化数据传输的问题。实际上 PHP 那套结构化 QueryString 传输是非常浪费的,特别是遇上长字段名时要重复写好多次,而且请求头又不会被 GZIP,导致流量浪费。使用 JSON 的话就可以很容易地定义个数组或对象类型。比如
'?list[]=1&list[]=2&list[]=3&list[]=4'; // PHP 风格 '?list=[1,2,3,4]'; // JSON 风格   当然,如果是对象传输的话 JSON 类型可能也挺吃亏,因为大量的 { } 会被转义为 %7B %7D,产生很多转义字符。不过比起 PHP 那套恶心的表达方式这已经非常好了。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^