如果我想在REST中实现一个复杂的查询呢

我想实现一个REST服务，它能够解析查询，比如检索startdate之后和EndDate之前创建的用户，并具有admin权限。标准REST实现似乎只能通过ID进行查询。我需要自定义协议来实现这种查询，还是需要任何标准

---

谢谢

就我而言，restful的东西对CRUD操作是有效的。您可以实现单独的

search

method/url，并根据需要传递尽可能多的参数。如果您仍然尝试遵循REST方法，那么您应该使用GET请求类型。

REST中没有任何约束规定您只能通过ID进行查询。使用一组查询参数返回一组符合这些搜索条件的用户绝对没有错。

Ryan Bates有一个Railscast，其中显示了创建作为资源进行搜索。即使您没有使用Rails，这个概念仍然有效

看一看。它是非常RESTful的，而且它们有一种非常好的方式来执行“复杂”查询，同时保持一个干净的URI

下面是一个示例，说明他们的干净查询URI是什么

http://example.com/jo/-/Fritz/2006

而不是

http://example.com/jo?category=Fritz&category=2006

来自谷歌：

这种方法在不使用查询参数的情况下识别资源，并生成更干净的URI。我们为类别选择这种方法，因为我们认为类别查询将是最常见的查询

---

我将django的字段查找语义作为复杂查找的指南。

不要因为它被定义为特定于语言的api而忽略，它很容易转换为html查询参数

例如

http://example.com/Goods?category=fruit&size__lt=14

---

要获得

select*from goods的结果，在sql中category='fruit'和size<14

，或者在xpath中

/goods[@category='fruit'和@size<14]

，或者其他任何东西。

我认为这是一个不错的方法，但它不能满足所有情况。是的。但它能让你保持正确的心态。URI应该被视为ID，而不是查询。不要把你的查询看成是搜索字符串或SQL，而应该把它看作是一个标识资源的ID（它本身可能是一组其他资源——在REST中超链接是一件大事）。URI中的查询字符串正是用于查询的。它不会使每个查询URI的方法无效，相反，它可以具有优势，特别是在缓存方面。发布复杂查询和发出重定向也是如此。这完全取决于您的需要，并且没有一个解决方案天生是无效的。这并不意味着在URI中使用查询字符串有任何问题。只是建议GData作为一种有趣的、不同的方式来思考搜索中的URI。我试图强调将搜索结果视为可识别的资源，搜索结果应该促进超链接。是的，ID/URI可以包含任何内容，并且URI的结构使其不具有更多或更少的RESTful/cacheable。由于明显的原因（POST请求的开销、缺少缓存、违反HTTP对POST的定义），从未提及发布搜索请求。>restful内容对CRUD操作有效-不，不是这样。@TechExchange您是对的。自从我回答这个问题后，我对REST的了解发生了变化。）