【问题标题】:Making PUT create request idempotent in REST API在 REST API 中使 PUT 创建请求幂等
【发布时间】:2018-05-31 01:12:00
【问题描述】:

我的目标是让 /create REST API 实现为 PUT 动词。

Idempotent RFC 状态:

区分幂等方法是因为请求可以
如果在此之前发生通信故障,则会自动重复
客户端能够读取服务器的响应。例如,如果一个
客户端发送 PUT 请求并关闭底层连接
在收到任何响应之前,客户端可以建立一个新的
连接并重试幂等请求。它知道重复 该请求将具有相同的预期效果,即使原始
请求成功,但响应可能不同。

PUT RFC 状态:

如果目标资源没有当前表示并且 PUT 成功创建一个,然后源服务器必须通知
用户代理通过发送 201(已创建)响应。如果目标
资源确实有一个当前的表示和那个表示
按照附上的状态修改成功 表示,则源服务器必须发送 200(OK)或 204(无内容)响应,表示成功完成
请求。

假设 /create 将创建的资源存储在 DB 中,是否应该在第一次创建时返回 201,在重试 /create 时返回 200? 是否应该重试 /create 将相同的资源重新存储在 DB 中以符合 PUT RFC?

【问题讨论】:

  • 使用 POST 保存,使用 PUT 更新。
  • 我的目标是让 PUT /create 具有幂等性。表示可以重试
  • 如何知道是创建资源还是更新资源?
  • 我会检查是否存在具有相同 id 的人
  • 你会得到ID吗?只是好奇,因为 PUT /PUT /:id 是 2 个不同的资源

标签: rest http put idempotent


【解决方案1】:

所以这个问题有点混乱。让我们看看能不能解开它。

PUT /create

abcde

粗略地说:用表示abcde 替换/create 的状态。换句话说,消息的语义类似于

store(key => "/create", value => "abcde")

请注意,处理此消息两次会产生与处理一次消息相同的效果。

store(key => "/create", value => "abcde")
store(key => "/create", value => "abcde")

请注意,我们在此处使用的密钥非常具体; PUT 与目标资源的状态有关; PUT /create 是要求我们修改/create 的消息,而不是我们创建一些其他资源的请求。

假设 /create 将创建的资源存储在 DB 中,是否应该在第一次创建时返回 201,在重试 /create 时返回 200?

是的。

是否应该重新尝试 /create 在 DB 中重新存储相同的资源以符合 PUT RFC?

如果 resource 已经有请求的representation,则不需要再次存储。

【讨论】:

  • 非常感谢。 如果资源已经具有请求的表示,则不需要再次存储它。 如果我做对了,实现它的唯一方法是从数据库中检索资源并将其与正文中的资源表示。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-11-05
  • 2017-05-01
  • 2019-11-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多