这是 RESTful 吗？

Question

我对集合 URI 应该返回什么感到有点困惑。

假设我有一个集合，/users 相当大的元素。然后我们有预期的：

GET /users/123           // returns user element with identifier 123

但是应该怎么做

GET /users

返回？如果集合很大，并且元素很大，那么返回所有元素可能不是一件好事。也许相反，/users 级别的GET 请求应该返回元素摘要（标识符和可能的一些属性），而/users/ 级别的GET 请求应该返回实际元素。然后你可以做类似的事情;

GET /users
   > [{name: abc, id: 1}, {name: def, id: 2}, {name: ghi, id: 3}, ...]
GET /users/2
   > {name: def, prop1: *, prop2: *, ...}

如果您想在完整请求它们之前预览重要的应用程序域属性，这可能是一种延迟加载数据的好方法。有了这个，为了应用查询，你会做类似的事情

GET /users?prop1=value           // returns element summaries of elements with prop1=value
GET /users/?prop1=value          // returns elements with prop1 = value

这种方法可以吗？或者其他方法作用于/users 然后松散意义..（例如PUT /users？）

Answer 1

我个人喜欢 /users 不返回所有用户但返回查询特定用户所需信息的样式。所以总结的方法是我通常会这样写。

如果您要过滤或查询，我会选择您提供的第一个：

GET /users?prop1=value

我不在乎第二个

GET /users/?prop1=value

因为它很容易被误解或导致令人困惑和意想不到的错误（缺少一个斜线仍然有效，但会完全改变结果）。

您可能希望使用替代 URL 的方法来根据搜索参数返回特定用户，例如

GET /users?prop1=value    // returns element summaries based on results of prop1 matching
GET /users/find?prop1=value // returns elements with prop1 = value

显然，您的措辞可能会改变（查找/搜索），或者您可以使用完全不同的 URI，但我会尽量避免两个不同的含义是一个字符/符号分开的情况，以避免意外错误。另一种选择是确保您在提供的文档中清楚地概述了这一点，以便任何使用您的 API 的人都会意识到这种潜力。

实际上，我会使用 all 结构来扩展它。

因此，我将提供以下功能，而不是使用查找/搜索：

GET /users                   // returns summaries
GET /users/#                 // returns element
GET /users/all               // returns all elements
GET /users/all?prop1=value   // returns all elements that match the filter