Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

我不会修改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成功响应的服务器应该发送任何标题字段，可能表示实现的可选功能服务器并适用于目标资源（例如，允许），包括本规范未定义的潜在扩展。

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

2 个答案: