这里嵌入了两个问题: 1)应该尝试创建资源，2)如果不能，会发生什么。

1) @cass链接的RFC表示 https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4

PUT方法请求创建目标资源的状态，或者用请求消息有效负载中包含的表示定义的状态替换目标资源的状态。给定表示的成功PUT将意味着在相同目标资源上的后续GET将导致在200 (OK)响应中发送等效的表示。

此外，Mozilla的文本 https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT

HTTP PUT请求方法创建一个新资源，或者用请求有效负载替换目标资源的表示。

此外，从原始的RFC (被上面的测试替换) https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

PUT方法请求将封闭的实体存储在提供的Request-URI下。如果请求URI引用已存在的资源，则应将包含的实体视为驻留在源服务器上的实体的修改版本。如果请求URI不指向现有资源，并且该URI能够被请求用户代理定义为新资源，则源服务器可以使用该URI创建资源。

这有点轶事，但Kubernetes API也小心地进行了这种区分，并通知它的修补程序的用户，如果他们真的意味着更新： https://kubernetes.io/docs/reference/using-api/api-concepts/#api-verbs

对于PUT请求，Kubernetes根据现有对象的状态在内部将其分类为create或update。更新不同于补丁；补丁的HTTP动词是补丁。

2在“如果失败会发生什么”方面，我认为代码取决于出错的地方：

• 400:由于负载错误而无法创建
• 409:由于冲突而无法创建-例如，输入JSON中的某些字段对其进行了某些全局唯一性检查
• 502/3-无法创建，因为它尝试调用数据库，但它已死

我不确定404是不是最好的代码，因为它没有告诉用户任何原因。