文章目录
  1. 1. 如何针对查询设计URI
  2. 2. 如何设计查询响应
  3. 3. 如何支持有大量输入的查询请求
  4. 4. 如何存储查询

查询信息是HTTP GET方法的一种常见应用,查询通常涉及三个组成部分,即过滤(filtering)、排序(sorting)和投影(projection)。过滤是基于一些过滤条件选择实体的一个子集的过程。排序会影响服务器是如何排列响应中结果的。投影是选择实体中哪些字段将被包含到结果的过程。只要关注URI和表述,查询设计还是相对简单的。客户端负责运行查询,服务器的职责包括设计URI来支持过滤、排序和投影,设计表述,设置合适的缓存头。

如何针对查询设计URI

使用查询参数让客户端来指定过滤器条件,排序条件和投影。将查询参数作为带有合理默认值的可选参数。为了支持常用查询,可以使用预定义的命名查询。比如:

http://www.example.org/book/978-0374292881/reviews?after=2009-08-15&sortbyAsc=date&fields=title 

也可以扩展查询,让客户端执行特定查询.如:

# 将查询参数值作为SQL WHERE子句的一部分 
http://www.example.org/movies?query='.title like 'war' and year > 2000 order by year' 
# 使用XPath表达式选择电影标题 
http://www.example.org/movies[year>2000&genre='war']/title 

特定查询(ad hoc query)对客户端来说很灵活,但是削弱了服务器优化数据存储和后端缓存的能力,从而降低了性能,并可能造成URI和数据存储方式的紧耦合。所以要避免那些使用通用查询语言(例如SQL或XPath)的特定查询。

HTTP头中一般断点下载时才用到Range和Content-Range实体头进行字节范围请求(Range:bytes=1102-1311)。有一些服务器在查询上也使用范围请求(Range: query:after=2009-08-15&sortByAsc=date),缓存可能会忽略这种非字节范围请求,应该避免使用,而查询参数则更容易实现与支持。

如何设计查询响应

服务器将查询响应的表述设计为集合资源,当没有查询到任何匹配的资源,返回一个空集合。

如何支持有大量输入的查询请求

尽管HTTP没有限制URI的长度,但它的一些实现处于安全原因对此进行限制,以避免缓存溢出,阻止用户将大量过滤条件编码到URI。使用HTTP POST来支持大查询。使用POST处理查询削弱了HTTP的统一接口。根据定义,GET才是用于安全、幂等地获取消息的。而且缓存把HOST方法的响应当成是不可缓存的,其后果是丧失了缓存能力,尤其增加了分页查询时的时延。然而在遇到实际限制时,这种权衡也是必不可少的。

如何存储查询

服务器可以使用查询存储让那些使用POST方式发送的查询变得可以缓存。当客户端使用POST发起一个查询请求时,服务器创建一个包含查询条件的新查询资源,返回一个带有(指向新查询资源)Location头的响应码201(Created)。客户端对新查询资源发起GET请求,返回查询结果。如果客户端再用POST发起相同查询请求,服务器会找到匹配该请求的查询资源,客户端被重定向到该资源的URI上。存储查询弥补了使用POST方式处理查询的一些局限,缺点是不得不将查询永久保存为一个资源。此外,如果查询数量很大,服务器最终很有可能积聚大量不频繁使用的查询,需要频繁清理这些查询。而大量查询也会造成缓存命中率低下,缓存被很快占满,废弃很多不太使用的URI。

文章目录
  1. 1. 如何针对查询设计URI
  2. 2. 如何设计查询响应
  3. 3. 如何支持有大量输入的查询请求
  4. 4. 如何存储查询