Rest资源始终由Id？

Question

在RESTfull API中，表示资源过滤的最佳方式是什么？ 大多数示例都提到了结构为/resouce/9/subresource/5的URL。我希望代表一个像这样的资源的过滤列表：/resource/9/subresource/validated。这个validated属性是API领域中的顶级概念。

这是restfull api认为'好吗'？将验证移动到查询字符串感觉就像减少了这个概念的重要性。

编辑

让我试着解释我的问题有具体的例子：该api of stackexchange有以下资源：/users/{id}/notifications/unread。有人可能会争辩说，未读通知列表可以被视为一种资源。

Answer 1

如果你想要一个纯粹的REST API，请记住，每个资源类型是由同一个URL代表，所以像/resouce/9/subresource/5应该返回的东西比/resource/9/subresource/validated很大的不同。

我知道的大多数API使用查询参数来获取资源的一个子集（例如，用于过滤，分页等）。在你的情况下，这些网址就像/resource/9/subresource?validated=true

一些API遵循不同的方法，并有特定的URL作为过滤器（如你的/validated例子）。这背后的原因通常是，人们认为API的复杂性可能会非常大......如果设计不正确，就是这种情况。试想一下，如果你查询整个集合分页的作品，但在其他参数设置一些参数才有效，例如情况下不得，如果你只想要validated资源，与文档质量很差混合）

关于移动validated查询字符串..你能澄清为什么它会减少验证的概念？就REST API而言，资源是国王，而不是资源的属性。

（注意：我不知道你怎么在网址中使用反斜杠）

编辑

试图回答您的评论，因为我觉得这是很重要的！ :)。

如果这些网址返回包含相同的资源列表，比方说，一个用户，然后确认，删除，foobared等都是状态的用户，而用户是资源。

当我开始构建REST API时，我有类似的疑问，并且它确实需要思维转换。 URL必须表示资源，而不是状态或操作/命令。

编辑2

好吧，这解释了混乱。 Stack Exchange API ...实际上不是一个REST API（在该页面上甚至没有提到REST这个词）。它更像是一个RPC over HTTP，它使用JSON作为表示。

澄清上述声明（并在我被踢出网站之前）。REST通常被解释为有4个级别，您可以在此博客帖子上阅读Haters gonna HATEOAS。我在这里复制了关于符合REST级别的相关部分之一。

1. “POX的沼泽”您正在使用HTTP进行RPC调用。 HTTP仅用作隧道。
2. 资源。您不需要每次调用服务端点，都可以使用多个端点来表示资源，并且您正在与他们交谈。这是支持 REST的最初阶段。
3. HTTP动词。这是Rails为您提供的开箱即用级别：您可以使用HTTP动词 与这些资源进行交互，而不是始终使用POST。
4. 超媒体控件。 HATEOAS。您100％符合REST。

的StackExchange API是至多2级（1级将是使用类似SOAP 1个端点）。就我个人而言，如果它至少使用HTTP动词，我只会将API识别为“REST”，否则它仍然是RPC over HTTP，但唯一的区别是您有几个端点。

所以也许你的问题是：你想在你的API中实现什么级别的REST？在这里谨慎的说一句，尽管HATEOAS可能听起来很酷，但它会增加应用程序的复杂度......所以你必须问自己，如果你付出额外的复杂性是可以的（例如自动发现新操作） 。

非常重要的是，构建您认为最容易为您的客户使用的API。最好采取一种实用的方法来处理REST，而不是宗教式的方法，例如，这里是US White House REST standards。给我一个阅读，我真的同意大部分，如果不是全部，那里的做法。