rest - REST 资源 url 中的查询字符串

Question

今天我与一位同事讨论了在 REST URL 中使用查询字符串的问题。举这两个例子:

1. http://localhost/findbyproductcode/4xxheua
2. http://localhost/findbyproductcode?productcode=4xxheua

我的立场是 URL 应该按照示例 1 进行设计。这更清晰，而且我认为在 REST 中是正确的。在我看来，如果产品代码不存在，则从示例 1 返回 404 错误是完全正确的，而在示例 2 中返回 404 错误将是错误的，因为页面应该存在。他的立场是这并不重要，他们都做同样的事情。

由于我们都找不到具体的证据(诚然，我的搜索并不广泛)，我想知道其他人对此的看法。

Answer 1

从客户端的角度来看，这两个 URI 没有区别。 URI 对客户端来说是不透明的。使用更清晰地映射到您的服务器端基础设施中的那个。

就 REST 而言，绝对没有区别。我相信这么多人相信只有路径组件标识资源的原因是因为 RFC 2396 中的以下行

The query component is a string of information to be interpreted by the resource.

此行后来在 RFC 3986 中更改成为:

The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource

恕我直言，这意味着在识别资源时，查询字符串和路径段在功能上是等效的。

<小时/>

更新以解决 Steve 的评论。

如果我反对“清洁工”这个形容词，请原谅我。这实在是太主观了。不过，你确实说得有道理，我错过了问题的一个重要部分。

我认为是否返回 404 的答案取决于正在检索的资源是什么。它是搜索结果的表示，还是产品的表示？要了解这一点，您确实需要查看引导我们到达该 URL 的链接关系。

如果 URL 应该返回产品表示，那么如果代码不存在，则应返回 404。如果 URL 返回搜索结果，则不应返回 404。

最终的结果是，URL 的外观并不是决定因素。话虽如此，查询字符串通常用于返回搜索结果，因此当您不想返回 404 时，使用这种风格的 URL 会更直观。