我的目标是制作idempotent / create REST API，它实现为PUT动词。
可以区分幂等方法，因为请求可以是
如果在通信失败之前发生通信，则自动重复 客户端能够读取服务器的响应。例如，如果是 客户端发送PUT请求，底层连接关闭 在收到任何回复之前，客户可以建立新的 连接并重试幂等请求。它知道重复 请求将具有相同的预期效果，即使原件为 请求成功，但响应可能不同。
PUT RFC州：
如果目标资源没有当前表示而且 PUT成功创建一个，然后原始服务器必须通知
用户代理通过发送201（已创建）响应。如果目标是 资源确实有当前的表示和表示 根据所附的状态成功修改 表示，然后原始服务器必须发送200（OK）或 204（无内容）回复表示成功完成了 请求。
假设/ create将创建的资源存储在DB中，它应该在第一次创建时返回201，在重试/创建时返回200吗？ 应该重新/重新创建在DB中存储相同的资源以符合PUT RFC吗？
答案 0 :(得分：1)
所以这个问题有点困惑。让我们看看我们是否可以解开它。
PUT /create
abcde
粗略地说：用表示/create替换abcde的状态。换句话说，消息的语义类似于
store(key => "/create", value => "abcde")
请注意，处理此消息两次产生的效果与处理消息一次相同。
store(key => "/create", value => "abcde")
store(key => "/create", value => "abcde")
请注意，我们对此处使用的密钥非常具体; PUT与目标资源的状态有关; PUT /create是一条消息，要求我们修改/create，而不是我们创建一些其他资源的请求。
假设/ create将创建的资源存储在DB中，它应该在第一次创建时返回201，在重试/创建时返回200吗？
是。
重试/创建是否应该再次在DB中存储相同的资源以符合PUT RFC？
如果资源已经具有所请求的表示，则无需再次存储。