我正在开发一个 REST 服务,我的一个服务器端操作以一种可能需要一段时间的方式操作数据库,但是一旦操作开始,数据库就无法恢复(这是来自我们系统的约束正在我们的服务器上使用。我也许可以在以后的版本中更改它,但现在我们被这个限制所困扰)。
结果是在允许操作运行之前,我需要一个带有警告的“确定/取消”对话框。

起初我想将创建对话框的逻辑放在客户端,但这似乎违反了 HATEOAS(例如,如果我确实更改了服务器端的框架,则不需要对话框,但我赢了如果我的 API 保持不变,就不想更改客户端)。
我的下一个解决方案是返回带有警告的响应,以及链接到不同 POST 操作的 ok,但我不确定何时发送参数。我是否在第一个 POST 中发送参数?如果是这样,他们如何到达第二个 POST(当然,不保持应用程序状态)?仅将参数发送到第二个 POST 不是一种选择,因为只有 HATEOAS 会确定是否需要第二个。

我在这里发现了一个类似的问题:
REST, HTTP DELETE and parameters
但这有两个问题:

  • 它并没有解决我们的问题(因为他只在第二次尝试时添加了一个参数,但我需要从第一次携带我的参数)。
  • DELETE 必须符合“统一接口(interface)”。
    他确实提出了一个有效的观点,即并非所有客户端都需要确认,但是将整个对话框放在 UI 中让我回到了我们的问题,即如果我改进我的服务器端应用程序会发生什么。

  • 我很高兴听到您对此事的看法。

    P.S:这是我在 stackoverflow.com 上的第一篇文章(经过多年使用它来查找我之前提出的问题的答案),所以如果问题的格式不太正确,请原谅我(欢迎您更正当然是我)。

    请您参考如下方法:

    您的服务器端操作之一需要确认才能执行。在我看来,这意味着两个不同的调用,例如,这可能意味着首先检查您是否需要确认,然后执行实际操作。

    例如,您可以请求客户端首先执行 GET 以查看是否需要确认并检索要显示的消息,然后执行实际的 POST 操作。如果您首先没有 GET 请求,则 POST 可能会返回 4xx(可能是 412?)错误。

    但是,请记住,无论您做什么,都需要客户的合作。即使服务器确实收到了 GET 请求,客户端也可能会收到响应,但不会显示确认并进行发布,这不是您可以 100% 解决服务器端的问题。


    评论关闭
    IT序号网

    微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!