RESTFul体系结构中的唯一约束

Question

凭借15年的有状态客户端 - 服务器软件开发经验（以及它固有的问题），我仍然试图在RestFul架构中掌握无状态的概念。

假设我有一个通用接口将业务对象发布到我的REST服务。例如用户资源。我的用户资源应该限制其电子邮件地址的唯一性。我最初的反应是使用底层的数据库工具“garantuee”这个。第二个反应是引入一些锁定或交易机制。

但我的Restafarian同事回答：'不！'客户端应检查新用户的电子邮件是否唯一，您应该接受这样一个事实，即可以插入重复的电子邮件地址的小窗口时间。客户端应用程序应该能够处理这种冲突。

这反过来反对我所学到的一切，根本不自然。请赐教......

Answer 1

我认为没有理由不返回相应的HTTP code：409冲突。这可以在从数据库中获取错误时返回。

出于可用性原因，在发送请求之前检查电子邮件地址是否唯一是很好的，因为您可以提示用户（并禁用提交）来解决问题。无论如何，仍然建议服务器端验证。

Answer 2

这与协议无状态无关。无状态只表示服务器不应该是一个与会话相关的保存状态（http://en.wikipedia.org/wiki/Stateless_protocol）。

在您的情况下，用户资源不是会话状态 - 它们是存储在服务器上并由服务器公开的持久资源。没有理由强迫客户端执行此检查（通过迭代获取和检查所有用户资源），并且使服务器执行此操作更有意义。这个检查是由服务器作为POST新用户资源的一部分完成的，还是存在一个启用此检查的单独资源 - 它实际上没有区别，因为服务器正在进行此检查。如果您使用单独的资源来首先检查是否可以发布新用户，然后发出新请求以实际执行POST - 那么可能存在重复的电子邮件地址。在这种情况下，预期的行为是服务器通知客户端POST请求失败（使用适当的HTTP响应代码，就像客户端检查电子邮件正常的第一个请求一样）。

简而言之：服务器执行“检查”，客户端应该能够处理服务器通知它检查失败的情况。