【问题标题】:Unique Constraint in a RESTFul architectureRESTFul 架构中的独特约束
【发布时间】:2012-09-09 12:08:47
【问题描述】:

拥有 15 年的有状态客户端-服务器软件开发经验(这是固有的问题),我仍在尝试掌握 RestFul 架构中无状态的概念。

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

但我的 Restafarian 同事回答:“不!”客户端应该检查新用户的电子邮件是否是唯一的,并且您应该接受这样一个事实,即有一小段时间可以插入重复的电子邮件地址。客户端应用程序应该能够处理此冲突。

这反过来又与我所学的一切背道而驰,而且一点也不自然。请赐教...

【问题讨论】:

    标签: database http rest stateless


    【解决方案1】:

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

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

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

    【讨论】:

      【解决方案2】:

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

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-01-22
        • 2012-11-07
        • 2016-05-14
        • 1970-01-01
        相关资源
        最近更新 更多