Web 技术研究所

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

REST API 设计之 —— 区间问题

  在标准的 QueryString 中,我们传递的参数总是以 name=value 的形式提交。关键是中间一定是等号,不存在大于号小于号之类的东西。那如果需要查询一个范围该怎么办呢?于是我们需要引入区间的概念。而且不仅是简单的从什么到什么,还有开闭区间的概念要考虑。
  在数学中,区间可以用两个逗号隔开的数字描述,并且可以用小括号和中括号表示开区间和闭区间。虽然使用这种格式可以解决问题,但我觉得把括号用在这种地方实在是很蛋疼。而且如果遇到一边开一边闭的区间,结果将是一边小括号一边中括号,简直难看到爆不是?
  区间的开闭合状态即使用文字描述也是一件痛苦的事情。比如在我自己的逻辑中「x 以下」表示「小于 x」,但很多时候它实际上是表示「小于或等于 x」。典型的就是「中华人民共和国刑法释义」中的第 99 条「本法所称以上、以下、以内,包括本数」。
  其实对于数值类型,无论什么样区间都没问题。因为只要数字的精度是有限的就很容易修改数字来切换区间的开闭状态。但问题来了,如果是日期类型就麻烦了。比如我需要一个描述 2014 年中所有天的日期区间,那么我们可能会写 x >= 2014-01-01 && x < 2015-01-01。如果不这么写,而把右边的区间也打开,那就需要考虑 12 月到底是大月还是小月,最用一天到底是什么日期。其实这还是个简单的例子,因为日期类型可以转换成 Unix 时间戳来计算区间,虽然会严重降低可读性,但是至少能解决这个问题。一些根本无法数值化类型如果有区间计算的需求那就真没法通过简单地改变值来实现了。
  其实这个问题已经超出了 Web API 的层面了,因为 SQL 语句如果已经封装好,后端也仅仅是调用而已。如果里面写死了开闭区间,后端也同样会遇到前端一样的问题。所以如果在 API 设计中如果把开闭区间的控制放出来会造成 DBA 的工作量很大。其实我们确实是用不着对所有的区间都考虑开闭,根据业务逻辑封装相应的查询接口即可。这样前端不需要考虑区间问题,后端也不需要考虑请求查询条件包装问题,DBA 只要针对业务需求做优化即可。
  我的建议是,如果没有特殊需求就不要把开闭区间暴露在 API 中。如果真有这样的需求可以考虑多参数实现。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^