具有经过身份验证的用户的REST API的无状态

Question

我正在设计一个REST Http api.(使用HATEOAS的东西,让客户"更简单",并避免客户做复杂的事情,而不是让api告诉他们该怎么做......)

由于应用程序的社交特性,为了与应用程序交互,用户需要进行身份验证,并且每个用户都会对数据略有不同的"视图".我们以twitter为例,对每个人来说都会更容易.

要对用户进行身份验证,我们将轻松使用OAuth.

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

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使用资源时,呈现的有效状态转换在响应中具有超媒体控件(链接和表单).通过遵循这些链接并提交表单,客户可以更改这些资源的状态.

Answer 2

在响应主体中包含关系类型的描述不会破坏无状态约束.无状态约束意味着Web服务器可以响应请求而不依赖于任何先前的请求(如Tom,Jacob和kgb所述).

我没有资格说出你所做的是否是"最佳实践",但总的来说,罗伊提出以下理由支持和反对使你的API无国籍(参见他的论文第5.1.3节).像生活中的许多事情一样,有一个权衡:

无国籍系统的问题

• 请求可能需要更大.由于数据未在请求之间存储在服务器上,因此每个请求可能需要一遍又一遍地包含相同的内容.

• 在无状态系统中,服务器依赖于客户端正确维护状态.

无国籍系统的好处

• 您知道请求仅根据其内容尝试实现的目标.

• 可靠性,因为它"简化了从部分故障中恢复的任务".请参见参考133中引用罗伊的论文获得更多信息.

• 改进了可扩展性.在请求之间管理状态,特别是在分布式环境中,可能非常复杂.这里首先想到的是ASP.NET InProc会话状态,适用于单个服务器,单个流程实例,但它不能很好地扩展.

RESTful资源

此外,根据Roy对资源的定义,我会对我认为您定义资源的方式产生疑问,每个用户都会对数据略有不同的"视图".Roy将资源定义为随时间变化的隶属函数(参见论文中的 5.2.1.1节).您在上面定义的用户列表资源因时间和授权标头而异.同时请求/用户的两个不同客户端很可能最终得到完全不同的结果.这将使缓存结果更加困难.

编辑:使用HTTP vary标头将允许它被缓存.