这是RESTfull吗？

Question

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

假设我有一个集合，/users的大元素。那么我们就有了预期的：

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

但应该怎么做

GET /users

回来？如果集合很大，元素也很大，那么返回所有元素可能不是件好事。也许相反，GET请求在/users级别应该返回元素摘要(标识符和一些属性)，而/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的人注意到这种可能性。

实际上，在此基础上，我将使用所有的构造。

因此，我不使用查找/搜索，而是提供：

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