将 POST 用作 UPDATE 或 CREATE 时是否违反了 RESTful

Question

鉴于其他部门对我们的 REST API 的要求，他们希望将 POST 不仅用于 CREATE，还用于 UPDATE OR CREATE。我知道在 RESTful API 中 PUT 可以或应该用于此目的，但由于客户端必须更新用于构建 URI 的信息，我们不能使用它。它将更改 URI 并使 PUT 不再具有幂等性...（在第一个 PUT 之后旧的 URI 将不存在）。
tl;dr 我们不能使用 PUT

在HTTP/1.1 specs POST 中定义为

POST 方法用于请求源服务器接受 包含在请求中的实体作为资源的新下属 由 Request-URI 标识

还有

POST 方法执行的操作可能不会产生资源 可以通过 URI 识别。

为了保持 RESTful，我会将更新功能解释为删除旧元素，然后创建新元素，这对于 POST 来说是可以接受的功能。

我们会在创建成功时返回#201，在更新时返回#200。

---

在我们的 API 中，“有可能”在没有 URI 的情况下处理正确的元素（例如，使用 POST 更新它），因为所有 URI 构建主键部分都在资源主体中，因此 API知道客户想要访问哪个元素。

---

示例

（这只是POST 的行为示例。不适用于资源的数据结构。当然使用PUT 对/cars/ 来说是完全正确的） p>

POST /cars/ HTTP/1.1
<car>
    <id>7</id>
    <status>broken</status>
</car>

回复：#201
然后

POST /cars/ HTTP/1.1
<car>
    <id>7</id>
    <status>fine</status>
</car>

回复：#200
现在/cars/7 上的GET 将返回以下内容：

<car>
    <id>7</id>
    <status>fine</status>
</car>

Answer 1

“违反 RESTfulness”没有严格定义。

degrees 接口中类似 REST 的行为的一个很好的参考是 Richardson Maturity Model，它将对 REST 理想的支持程度分为 4 层（其中 0 表示“根本不是 REST”，并且3 是“完全 REST，但几乎没有人这样做”）

在此模型的第 2 级基于 RESTful HTTP 的设计中，您的选择仅略有不同。然而，这是许多现实世界项目必须应对的妥协。

POST 是开放式的，如果您愿意，它可以是幂等的，但 HTTP 不需要它。所以你并没有破坏 HTTP，只是错过了使用更密切的 PUT 方法的机会。相反的情况，将 PUT 用于 API 的非幂等部分，问题会更大。

作为个人观点，我认为如果您在处理不同的 HTTP 方法和路由时保持自洽，并清楚地记录这种预期的变化，那么您可以合理地将您的 API 称为“RESTful”。我认为响应代码拆分 200/201 足以编写一个自洽的客户端。虽然我更希望在这里看到 create 和 update 都作为 PUT，但这不会让我停顿片刻。

您可能会考虑按照建议在收集路线上支持 update 或 create（在您的示例中为 POST /cars），并在项目路线上支持 update (POST /cars/7) . “更新或创建”的概念在数据库和 ORM 框架中很常见，很容易理解。客户端也可以使用后一种仅更新路由，因为它不会意外地自动创建新记录。

Answer 2

自然不能保证服务器不 由于执行 GET 请求而产生副作用；在 事实上，一些动态资源认为这是一个特性。重要的 这里的区别是用户没有请求副作用，所以 因此不能对他们负责。

方法也可以具有“幂等性”的属性（除了 来自错误或过期问题）N > 0 的副作用相同 requests 与单个请求相同。

所以幂等性是关于服务器端的副作用。你的第二个 PUT 没有任何其他副作用（因为 404），而不是第一个，所以在这里使用 PUT 是幂等的。

POST 方法用于请求源服务器接受 包含在请求中的实体作为资源的新下属 由 Request-URI 标识

在这种情况下，您无需创建新资源，只需添加新资源标识符并删除旧资源标识符。所以POST是不合适的。

POST 方法执行的操作可能不会产生资源 可以通过 URI 识别。

这可能意味着你想要的任何东西......当他们没有选择时，Ppl 将 POST 用于非创作目的，但你肯定不是。

在我们的 API 中，“有可能”在没有 URI（例如，使用 POST 更新它），因为所有 URI 都在构建 主键部分在资源体中，所以 API 知道哪个 客户想要访问的元素。

如果您不想违反统一接口（资源识别）约束，则必须使用 IRI (URL) 来识别资源。

如果您不想违反统一接口（超媒体作为应用程序状态的引擎）约束，则必须使用超链接。 IRI 结构不为客户端携带任何语义，所以它可以是任何东西，如果由它们决定的话。您必须使用链接关系或词汇中的某些属性来添加语义。

如果您不想违反统一接口（自描述消息）约束，则必须至少使用供应商特定的 MIME 类型。

根据定义，REST web 服务满足所有REST constraints。术语 RESTful 是在人们开始将他们的 Web 服务称为 REST 时创建的——他们对 REST 毫无概念。因此，在那之后，人们创建了 RESTful 术语，这意味着所谓的 REST 服务不违反任何 REST 约束。在那之后，RESTful 一词也用尽了。现在我们区分超媒体 API 和 Web API。超媒体 API 意味着 Web 服务符合 HATEOAS（超媒体作为应用程序状态引擎）约束。 Web API 可以是任何声称是 REST 的东西。