为需要确认的RESTful POST请求提供参数

时间:2016-03-02 06:33:34

标签: rest

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

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

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

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

    PS:这是我在stackoverflow.com上的第一篇文章(经过多年使用它来查找我面前提出的问题的答案),所以请原谅我问题的格式是不是很正确(你是当然欢迎纠正我。

2 个答案:

答案 0 :(得分:1)

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

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

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

答案 1 :(得分:0)

我不会修改DELETE的语义,就像链接文章中的一个解决方案一样(返回4xx强制新请求)。让DELETE无法正常工作会让大多数人感到惊讶,应尽可能避免意外。

我的第一个想法是,您可以像HTML中的确认对话框一样解决它。这是将一些代码放入链接,或者可能是一些标志,表明它需要删除确认:

<a rel="something" onDelete="confirm" href="..."/>
<a rel="something" onDelete="showConfirmation()" href="..."/>

这一开始似乎没问题,但这真的是链接的属性吗?好吧,阅读您对问题的描述似乎您正在定义POST操作本身的某些功能是否存在。此功能是可恢复性还是可回滚性?因此,如果客户端需要检测某个操作的某些功能,它可以使用OPTIONS这样的请求:

OPTIONS /something/abc HTTP/1.1
...

200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
...
<body describing confirmation dialogs, messages, etc>

基本上,您可以通过OPTIONS的自定义表示来宣布该功能。规范明确允许这个(https://tools.ietf.org/html/rfc7231#section-4.3.7):

  

生成对OPTIONS成功响应的服务器应该发送任何      标题字段,可能表示实现的可选功能      服务器并适用于目标资源(例如,允许),      包括本规范未定义的潜在扩展。