Justin的答案可能是正确的，尽管在某些应用程序中，将特定的搜索视为其本身的资源可能是有意义的，比如如果你想支持命名保存的搜索:

/search/{searchQuery}

or

/search/{savedSearchName}

Justin的答案可能是正确的，尽管在某些应用程序中，将特定的搜索视为其本身的资源可能是有意义的，比如如果你想支持命名保存的搜索:

/search/{searchQuery}

or

/search/{savedSearchName}

我使用两种方法来实现搜索。

1)最简单的情况，用于查询相关元素，并用于导航。

    /cars?q.garage.id.eq=1

这意味着，查询车库ID等于1的汽车。

也可以创建更复杂的搜索:

    /cars?q.garage.street.eq=FirstStreet&q.color.ne=red&offset=300&max=100

FirstStreet所有车库中不是红色的汽车(第三页，每页100个元素)。

2)复杂查询被认为是常规资源，可以被创建和恢复。

    POST /searches  => Create
    GET  /searches/1  => Recover search
    GET  /searches/1?offset=300&max=100  => pagination in search

创建搜索的POST正文如下:

    {  
       "$class":"test.Car",
       "$q":{
          "$eq" : { "color" : "red" },
          "garage" : {
             "$ne" : { "street" : "FirstStreet" }
          }
       }
    }

它基于Grails(标准DSL): http://grails.org/doc/2.4.3/ref/Domain%20Classes/createCriteria.html

对于搜索，使用querystrings。这是完美的RESTful:

/cars?color=blue&type=sedan&doors=4

常规查询字符串的一个优点是它们是标准的、被广泛理解的，并且它们可以从form-get生成。

虽然我喜欢贾斯汀的回答，但我觉得它更准确地代表了一种过滤，而不是一种搜索。如果我想知道以小卡开头的车呢? 在我看来，你可以把它构建到你处理特定资源的方式中: /汽车/ cam * 或者，你可以简单地将它添加到过滤器中: /汽车/门/ 4 /名称/ cam * /颜色/红色、蓝色、绿色 就我个人而言，我更喜欢后者，但我绝不是REST方面的专家(我第一次听说REST只是在两周前左右……)

对于你的情况，这里有很多好的选择。你仍然应该考虑使用POST主体。

查询字符串非常适合您的示例，但如果您有更复杂的东西，例如任意长的项目列表或布尔条件，您可能想要将post定义为一个文档，客户端通过post发送。

这允许更灵活的搜索描述，以及避免服务器URL长度限制。