在RESTfull API中，表示资源过滤的最佳方式是什么？
大多数示例都提到了结构/resouce/9/subresource/5的网址。我希望代表一个过滤的资源列表，如下所示：/resource/9/subresource/validated。此validated属性是API域中的顶级概念。
在restfull api中这被认为是'好的'吗？将验证字符移动到查询字符串感觉就像它减少了概念的重要性。
修改
让我试着用一个具体的例子解释我的问题：api of stackexchange有以下资源：/users/{id}/notifications/unread。有人可能会争辩说，未读通知列表可以单独被视为资源。
答案 0 :(得分：3)
如果您需要纯粹的REST API，请记住每个资源类型都由相同的网址表示，因此/resouce/9/subresource/5之类的内容应返回与/resource/9/subresource/validated非常不同的内容。
我知道的大多数API使用查询参数来获取资源的子集（例如，用于过滤，分页等）。在你的情况下，网址将类似于/resource/9/subresource?validated=true
某些API遵循不同的方法，并且具有可用作过滤器的特定网址（如/validated示例）。这背后的原因通常是，人们认为API的复杂性可能相当大......如果设计不当，就会出现这种情况。想象一下，某些参数仅在设置其他参数时起作用，例如，如果您查询整个集合，则分页有效，但如果您只需要validated资源，则混合使用不良文档时
关于将validated移动到查询字符串..您能否澄清为什么它会削弱验证的概念？与REST API一样，资源是王者，而不是资源的属性。
（注意：我不知道你如何在你的网址上使用反斜杠）
我认为这很重要，试着回答你的评论！ ：）
如果这些网址返回包含相同资源的列表，请说明用户，然后验证，删除，填充等等状态用户，而用户是资源。
当我开始构建REST API时，我有类似的疑虑，它确实需要思维转换。 URL必须代表资源，而不是状态或操作/命令。
好的，这解释了混乱。 Stack Exchange API ......实际上并不是一个REST API（在该页面上甚至没有提到REST这个词）。它更像是RPC over HTTP，它使用JSON作为表示。
澄清上述陈述（在我被赶出网站之前;）。 REST通常被解释为有4个级别，您可以在此博客文章Haters gonna HATEOAS上阅读。我在这里复制了关于REST一致性水平的相关内容之一。
- “POX的沼泽。”您正在使用HTTP进行RPC调用。 HTTP仅用作隧道。
- 资源。您可以使用多个端点来表示资源，而不是每次调用服务端点 你跟他们说话。这是支持的开始 REST。
- HTTP动词。这是Rails之类的东西开箱即用的水平：你使用HTTP动词与这些资源进行交互， 而不是总是使用POST。
- 超媒体控制。 HATEOAS。您是100％REST兼容的。
StackExchange API最多在级别2（级别1将使用类似SOAP的1个端点）。就个人而言，我只认识一个API为“REST＆＃39;如果它至少使用HTTP谓词，否则它仍然是RPC over HTTP，但唯一的区别是你有几个端点。
所以也许你的问题是：你想在API中实现什么级别的REST？这里需要注意的是，完整的HATEOAS可能听起来很酷，但它会增加应用程序的复杂性......所以你必须问问自己，你是否可以支付额外的复杂性（例如自动发现新的操作）。
非常重要的是，构建您认为最容易为您的客户使用的API。采用实用的REST方法而非宗教方法更好，例如，这里是US White House REST standards。给那个阅读，我真的同意那里的大多数（如果不是全部）实践。