【问题标题】:Should idempotent service respond with error after first call?第一次调用后,幂等服务是否应该以错误响应?
【发布时间】:2014-10-02 10:15:07
【问题描述】:

我正在为 DDD 应用程序编写服务层。
服务通过 WSS 上的 JSON-RPC 公开。
我不确定如何响应多余的服务调用。

关于系统的一些事实:

  1. 所有请求必须在特定时间内完成,否则会出现超时异常。
  2. 如果系统负载过重,它可能会决定放弃请求(显示为超时)。
  3. 如果系统负载过重,队列中的某些消息可能过期(显示为超时)。
  4. 即使请求到达它的目的地 ACK 也可能无法到达用户 时间(显示为超时)。
  5. 如果 ACK 未及时到达,最终用户有权重新调用方法。

不保证请求完成。 因此需要幂等性。

如果我们考虑 [4]+[5] 的含义,就会出现问题:

  • 用户调用方法 setFoo(Bar)。
    • 实体已创建,但 ACK 未按时完成。
  • 用户收到超时并认为他应该再试一次,所以他重新调用 setFoo(Bar)。
  • 实体已存在 -> 嗯...

问题是:用户应该得到 ACK 还是错误(我已经完成了那个伙伴...)?

【问题讨论】:

    标签: web-services service domain-driven-design json-rpc idempotent


    【解决方案1】:

    一个幂等操作在被多次调用时应该具有相同的行为。这表明返回值也应该相同,因此在您上面描述的场景中,用户应该得到 ACK。

    考虑替代方案;如果你向用户返回错误,那么用户应该如何响应?什么“错误处理”是合适的?

    您可以为 ACK(Ive done that mate...) 的响应提出论据,但括号中的部分应该是一个纯可选的信息字段,而不是影响如何用户处理响应。

    【讨论】:

    • 可以说,即使方法返回错误,它也不会改变应用程序(服务器端)的状态,也不会产生副作用。因此我们仍然可以说它是幂等的。
    • 从服务器的角度来看是幂等的,但从用户的角度来看不是。您是否希望调用服务器的操作也具有幂等性?
    • 我喜欢 ACK 中“元数据”的想法。也许所有与幂等性相关的错误(存在等)都应该作为元数据附加。谢谢你。
    • 是的,我愿意。我担心会丢失有关操作成功原因的信息的情况。例如:我想给用户X添加读权限。执行后我得到了ACK(Y先生已经把这个权限给了用户X)。基本满足了意图,但操作不成功。这种类型的区别在许多情况下对 UI 来说是有意义的,否则很难实现。
    猜你喜欢
    • 1970-01-01
    • 2018-12-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多