REST API - 当搜索条件 (queryParams) 没有产生任何结果时 return 做什么
REST API - What to return when search criteria (queryParams) doesn't yield any results
我正在设计 REST API 并且在整个 API 中，当我们尝试访问的 object/resource 不存在时，我们使用了 HTTP Not found / 404。
Ex: http://host/someobject/1
但目前的情况略有不同。我有使用查询参数搜索数据的 URI。
Ex: http://host/someObject/find?param1=param1value¶m2=param2value
查询参数是可选的，但至少必须提供一个条件才能成功请求。当搜索结果为空时，假设 URI 存在但数据目前不存在，我目前正在 returning 空列表。
任何人都可以阐明这种情况吗？我应该 return 状态码为 200 的空数组还是其他？
As 404表示：404 – Not found – URI后面没有资源
我会说，当 URI 和参数有效时，returning 一个空列表是有效的。
您可以 return 204：204 无内容
TL;DR - return 使用 N = 0.
与 N 结果相同 return
http://host/someObject/find?param1=param1value¶m2=param2value
请记住，从 REST/HTTP 的角度来看，上面的 URI 不是 查询；它是信息资源的标识符。标识符的一部分（由 RFC-3986 命名为 Query）只是“非分层数据”。
您的实现解析 URI，并将它找到的标记用作查询的输入这一事实是一个实现细节，并且通过统一接口故意对客户端隐藏。 （例如，考虑客户端 GET 请求通过客户端和服务器之间的缓存的情况；缓存可能使用 URI 作为键值存储中的查找，并且——找到那里的表示——将发送结果返回给客户端而不将请求转发给服务器）。
理想情况下，您的资源及其表示将是稳定的，即使您的实现可能不稳定。
The query parameters are optional but at least one criteria must be provided for successful request. I am currently returning empty list when search result is empty assuming the URI exists but data not present at the moment.
完美。
I assume the comment of you says my implementation is fine ?
是的。
Also i found some of the persons saying verb shouldn't be there and representation should be objects/?param=value or Objects?param=value.
快速概览
REST 不关心资源标识符的拼写
网络也不是——就网络的其他部分而言，您的 URI 是不透明的。客户端代码不应该解释标识符，或者以任何方式依赖它们的解释。唯一应该关心的是源服务器（它需要将标识符路由到适当的实现）。
您引用的“规则”类似于推荐变量名最佳实践的编码风格指南。该规则的 动机 基于 REST 和网络；不是通过规范，而是通过更深层次的想法....菲尔丁的 definition of resources:
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource.
REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.
由此可见，return表示的任何资源都必须是具有状态的事物。因此，命名准则鼓励将资源标识为名词而不是动词的拼写。
“为我找到满足这些约束的对象”是您的 URI 所说的，但这与资源的概念不一致。准则鼓励您改为思考“获取满足以下约束的对象集合的当前状态”，然后选择与此资源一致的标识符。
I am pretty confused when I read these different blogs with different opinions
- 那不是你的错
- 如果你的母语是英语，你仍然会感到困惑
大多数程序员通过学习一些东西就可以了，然后通过询问附近的人来学习其余的东西。这意味着人们拥有的许多实用“知识”都来自口头传统；每当有新人讲述时，故事都会发生变化，并且会与其他事物混淆。
在 REST 的情况下，扭曲达到了这样一种程度，即了解原始故事的人开始寻找一个新名称来使用，只是为了能够重新引入原始想法。
在我看来，200 with empty list 和 204 No Content found 都是正确的实现。
200 成功意味着您能够成功地进行操作并且您正在 returning 结果。空列表是有效的结果集。
204 表示您尝试的操作成功并且服务器没有 return 任何东西。所以这也是有效的。
RESTful 的世界是如此精致，以至于在它结束时有时会出现您的个人喜好，而我的个人喜好将是 200 个空列表。
我正在设计 REST API 并且在整个 API 中，当我们尝试访问的 object/resource 不存在时，我们使用了 HTTP Not found / 404。
Ex: http://host/someobject/1
但目前的情况略有不同。我有使用查询参数搜索数据的 URI。
Ex: http://host/someObject/find?param1=param1value¶m2=param2value
查询参数是可选的，但至少必须提供一个条件才能成功请求。当搜索结果为空时，假设 URI 存在但数据目前不存在，我目前正在 returning 空列表。
任何人都可以阐明这种情况吗？我应该 return 状态码为 200 的空数组还是其他？
As 404表示：404 – Not found – URI后面没有资源 我会说，当 URI 和参数有效时，returning 一个空列表是有效的。
您可以 return 204：204 无内容
TL;DR - return 使用 N = 0.
与 N 结果相同 returnhttp://host/someObject/find?param1=param1value¶m2=param2value
请记住，从 REST/HTTP 的角度来看，上面的 URI 不是 查询；它是信息资源的标识符。标识符的一部分（由 RFC-3986 命名为 Query）只是“非分层数据”。
您的实现解析 URI，并将它找到的标记用作查询的输入这一事实是一个实现细节，并且通过统一接口故意对客户端隐藏。 （例如，考虑客户端 GET 请求通过客户端和服务器之间的缓存的情况；缓存可能使用 URI 作为键值存储中的查找，并且——找到那里的表示——将发送结果返回给客户端而不将请求转发给服务器）。
理想情况下，您的资源及其表示将是稳定的，即使您的实现可能不稳定。
The query parameters are optional but at least one criteria must be provided for successful request. I am currently returning empty list when search result is empty assuming the URI exists but data not present at the moment.
完美。
I assume the comment of you says my implementation is fine ?
是的。
Also i found some of the persons saying verb shouldn't be there and representation should be objects/?param=value or Objects?param=value.
快速概览
REST 不关心资源标识符的拼写 网络也不是——就网络的其他部分而言，您的 URI 是不透明的。客户端代码不应该解释标识符，或者以任何方式依赖它们的解释。唯一应该关心的是源服务器（它需要将标识符路由到适当的实现）。
您引用的“规则”类似于推荐变量名最佳实践的编码风格指南。该规则的 动机 基于 REST 和网络；不是通过规范，而是通过更深层次的想法....菲尔丁的 definition of resources:
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource.
REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.
由此可见，return表示的任何资源都必须是具有状态的事物。因此，命名准则鼓励将资源标识为名词而不是动词的拼写。
“为我找到满足这些约束的对象”是您的 URI 所说的，但这与资源的概念不一致。准则鼓励您改为思考“获取满足以下约束的对象集合的当前状态”，然后选择与此资源一致的标识符。
I am pretty confused when I read these different blogs with different opinions
- 那不是你的错
- 如果你的母语是英语，你仍然会感到困惑
大多数程序员通过学习一些东西就可以了，然后通过询问附近的人来学习其余的东西。这意味着人们拥有的许多实用“知识”都来自口头传统；每当有新人讲述时，故事都会发生变化，并且会与其他事物混淆。
在 REST 的情况下，扭曲达到了这样一种程度，即了解原始故事的人开始寻找一个新名称来使用，只是为了能够重新引入原始想法。
在我看来，200 with empty list 和 204 No Content found 都是正确的实现。
200 成功意味着您能够成功地进行操作并且您正在 returning 结果。空列表是有效的结果集。
204 表示您尝试的操作成功并且服务器没有 return 任何东西。所以这也是有效的。
RESTful 的世界是如此精致，以至于在它结束时有时会出现您的个人喜好，而我的个人喜好将是 200 个空列表。