2

我正在实现一个搜索 API，它允许搜索系统中的多种类型的对象（客户端、产品等）。哪种形式的 URI 更可取：

/clients/search
/products/search
...

或者

/search/clients
/search/products
...

/clients, /products 资源已经存在用于其他目的。

编辑：

我认为这无关紧要，但似乎确实如此，所以 - 搜索可能足够复杂，需要 POST 而不是 GET

谢谢，

亚历克斯

4

3 回答 3

2

这个建议看起来很合理：https ://blog.apigee.com/detail/restful_api_design_tips_for_search所以根据这个：

/clients/search
/products/search
...

高音使用不一致的结构：

Splunk 更喜欢search成为第一的概念：http: //docs.splunk.com/Documentation/Splunk/5.0.2/RESTAPI/RESTsearches。

因此，这些示例表明，没有单一的最佳方法可以做到这一点。我认为当您想将查询限制为先验已知资源时，最好使用第一个示例。否则使用全局搜索 -/search将所有其他编码为参数（参见 Freebase API：https ://developers.google.com/freebase/v1/search - 他们有自己的查询语言......）。

于 2013-03-17T13:11:44.900 回答
2

如果它是一个 RESTful API，则不需要在 URI 中使用“搜索”一词，因为产品是资源，HTTP 方法 GET 提供了动词。所以你可以做类似的事情；

  • GET /product/998827727/（通过 id 检索产品）
  • GET /product/?searchTerm=thingybob（使用搜索词查找产品）

也就是说，有时您的搜索词太复杂了，所以您需要一个实用资源，然后您就可以做类似的事情，POST /product-search/或者POST /product/search/因为产品是主要资源

于 2013-03-17T13:34:34.863 回答
1

恕我直言，这两种方法都是错误的。

问题：如果我向您的服务发送以下 HTTP 请求，我会得到什么：

GET /clients/search
Host: service.org

GET /products/search
Host: service.org

GET /search/clients
Host: service.org

GET /search/products
Host: service.org

如果 /search 和 /products 资源已经存在，为什么不重用它们并在搜索时发送必要的查询参数？例如：

GET /clients?gender=female&country=US
Host: service.org

如果客户端对“/clients”服务的请求将响应所有客户端的列表，如果 URI 包含查询参数服务将响应过滤结果。我认为创建这样的专用搜索资源的价值为零。

PS Twitter 的 URI 很糟糕。

于 2013-03-17T13:31:02.383 回答