api - 具有经过身份验证的用户的 REST api 的无状态性

Question

我目前正在设计一个 REST Http api。 (使用 HATEOAS 的东西，让客户“更简单”，避免客户做复杂的事情，而不是让 api 告诉他们该做什么……)

由于应用程序的社交特性，为了与应用程序进行交互，用户需要进行身份验证，每个用户对数据的“看法”都会略有不同。我们将以 Twitter 为例，这对每个人来说都会更容易。

为了验证用户身份，我们将使用 OAuth，很简单。

因此，在客户端(ios 应用...)中，随机用户可能会看到用户应该看到的列表:

Adrien: Following
John:   Not Following
Rambo:  Not Following

另一个用户可能会看到:

Adrien: Following
John:   Not Following
Rambo:  Following

要实现这一点，第一个解决方案是客户端(在 oauth 术语中，iphone/web/etc 应用程序)获取经过身份验证的用户关注的所有用户的列表，并且每次客户端显示一个列表，将每个用户与关注的用户列表进行比较，以了解它应该显示“未关注”还是“关注”。

请求/响应将是:

GET /users
Authorization: OAuth token...

[
  {"id": 1, "name": "Adrien"},
  {"id": 2, "name": "John"},
  {"id": 3, "name": "Rambo"}
]

和

GET /users/{myid}/following
Authorization: OAuth token...

[1, 3, 25, 1210, 9]

这似乎是完全无状态的。好。

现在，如果我想让客户端开发人员的工作更轻松，并直接在用户列表响应中嵌入每个用户相对于经过身份验证的用户的关系:

GET /users
Authorization: OAuth token...

[
  {"id": 1, "name": "Adrien", "relationship": "Following"},
  {"id": 2, "name": "John", "relationship": "Not Following"},
  {"id": 3, "name": "Rambo", "relationship": "Following"}
]

那么，问题:

• 看似打破了“无状态”的东西，真的打破了REST无状态的约束吗？
• 接下来，您认为 api 执行此操作是好还是坏？

Answer 1

您绝对应该将关系嵌入到用户列表响应中。强制客户计算它是不好的做法。

这不会破坏 REST 的无状态约束，因为无状态的是交互，而不是系统。服务器几乎总是必须存储和维护状态。例如，服务器需要维护谁在关注谁的状态。

最后，我认为您没有完全将超媒体的“状态”部分作为应用程序 状态 的引擎。基本上，资源是状态机。当您GET 资源时，有效的状态转换会在响应中显示超媒体控件(链接和表单)。通过访问这些链接并提交表单，客户可以更改这些资源的状态。