【问题标题】:REST "dry-run" option for PUT or POST用于 PUT 或 POST 的 REST“试运行”选项
【发布时间】:2013-04-04 14:39:15
【问题描述】:

有没有一种惯用的方法来实现这一点:

我需要 PUT/POST 给定的实体。但是,在实际投入使用之前,我需要对一个更不稳定的系统进行一些更改,如果可行,我将继续。

所以我会先询问 PUT/POST 是否可以接受,然后再实际执行 PUT/POST。

我曾想过只使用“试运行”查询参数,但感觉不是正确的方法。

更新:试图澄清我的问题。关键是第一个 PUT 只是为了验证实体。

Me           System A       Volatile System X
|    Dry PUT    |                    :
|-------------->|                    :
|               |                    :
|   20x / 40x   |                    :
|<--------------|                    :
|               :                    :
| Upon PUT OK do some related work   :
|----------------------------------->|
|               :                    |
| Work completely                    |
|<-----------------------------------|
|               :
|PUT (for real) :
|-------------->|
|               |
|     20x       |
|<--------------|

【问题讨论】:

  • 我猜“正确的方法”是做一个完整的 PUT,如果 PUT 不可接受,服务器应该返回一些 4xx 错误。
  • 问题是;如果它通过它将在另一个系统更改之前保存;这可能无法通过,从而使系统处于冲突状态。
  • 那么它不应该“通过”,它应该返回一个 4xx 错误代码。

标签: rest


【解决方案1】:

从逻辑上讲,我觉得这也许可以通过某种状态属性来解决。如果您使用的是 JSON,您可能会考虑添加这样的属性:

{
  "draft" : true
}

第一次执行 PUT 请求时,您将项目标记为草稿。它存储该项目,但不对其进行任何其他操作。

在您的服务器接受您的请求后,您可以在其他地方进行“相关工作”,如果也成功了,您可以向同一资源提交另一个 PUT 请求,这次将 draft 设置为 false

【讨论】:

  • 如果它是相同的资源,第二个请求将是一个补丁,对吧?否则,它将是“originalResource/draft”的 PUT
  • PUT 用于替换资源,因此您绝对可以在同一资源上再次使用PUTPATCH 通常仅在您想要对资源进行部分替换时使用。
  • 在这种情况下您不想将draft 设置为false 吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-01-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多