SoapUI RESTful - HTTP 方法

最常用的 HTTP 方法是 POST、GET、PUT、PATCH 和 DELETE。这些方法分别对应于创建、读取、更新和删除（或 CRUD）操作。还有许多其他方法，但它们的使用频率较低。在这些方法中，OPTIONS 和 HEAD 的使用频率高于其他方法。

POST

POST 方法用于创建新资源。它用于创建下属资源。即从属于其他（例如父级）资源。

换句话说，在创建新资源时，向父级发出 POST 请求，服务负责将新资源与父级关联，分配 ID（新资源 URI）等。

成功创建后，返回 HTTP 状态 201，并返回带有指向新创建资源的链接的位置标头，HTTP 状态为 201。

POST 既不安全也不幂等。因此，建议将其用于非幂等资源请求。

发出两个相同的 POST 请求将导致两个资源包含相同的信息。有时，它会根据定义的服务类型抛出错误消息。

HTTP GET 方法用于读取或检索资源的表示形式。在成功响应中，GET 返回 XML 或 JSON 表示形式和 HTTP 响应代码 200（OK）。在错误情况下，它通常会返回 404（未找到）或 400（错误请求）。

根据 HTTP 规范的设计，GET（以及 HEAD）请求仅用于读取数据而不会更改数据。因此，GET 被认为是安全的。

GET 可以调用而不会有数据修改或损坏的风险 - 调用一次与调用 10 次具有相同的效果。此外，GET 是幂等的，这意味着发出多个相同的请求会导致与单个请求相同的结果。

建议不要通过 GET 公开不安全的操作 - 它永远不应修改服务器上的任何资源。

PUT 用于更新现有资源。PUT 用作已知资源 URI，其请求主体包含原始资源的更新表示。

PUT 还可用于创建资源，其中资源 ID 由客户端而不是服务器选择。换句话说，如果 PUT 用作包含不存在的资源 ID 值的 URI。

POST 用于创建新资源并在主体表示中提供客户端定义的 ID。成功更新后，它会从 PUT 返回 200（如果主体中未返回任何内容，则返回 204）。

如果使用 PUT 进行创建，则在成功创建时返回 HTTP 状态 201。响应中的主体是可选的。

PUT 不是安全的操作，因为它会修改（或创建）服务器上的状态，但它是幂等的。如果用户使用 PUT 创建或更新资源，然后再次进行相同的调用，则资源仍然存在，并且具有与第一次调用时相同的状态。

建议保持 PUT 请求幂等。强烈建议对非幂等请求使用 POST。

PATCH 用于修改功能。PATCH 请求只需包含对资源的更改，而不是完整的资源。它类似于 PUT，但主体包含一组指令，描述应如何修改当前驻留在服务器上的资源以生成新版本。

这意味着 PATCH 主体不应只是资源的修改部分，而应采用某种修补语言，例如 JSON Patch 或 XML Patch。

PATCH 既不安全也不幂等。 PATCH 请求可以以幂等的方式发出，这也有助于防止在相似的时间范围内对同一资源的两个 PATCH 请求之间发生冲突而导致不良后果。

来自多个 PATCH 请求的冲突可能比 PUT 冲突更危险，因为某些补丁格式需要从已知的基点进行操作，否则它们会破坏资源。

使用此类补丁应用程序的客户端应使用条件请求，这样如果自客户端上次访问资源以来资源已更新，则请求将失败。

DELETE 用于删除由 URI 标识的资源。成功删除后，它将返回 HTTP 状态 200（OK）以及响应主体（已删除项目的表示）。否则，它将返回 HTTP 状态 204（无内容），没有响应主体。

换句话说，没有主体的 204 状态，或 JSEND 样式的响应和 HTTP 状态 200 是推荐的响应。

HTTP 规范方面，DELETE 操作是幂等的。如果用户删除资源，则该资源将被删除。对同一资源反复调用 DELETE 会导致相同的结果：资源消失。

第二次对资源调用 DELETE 通常会返回 404（未找到），因为它已被删除，因此无法再找到。这使得 DELETE 操作不再是幂等的，但是资源的最终状态是相同的。返回 404 是可以接受的，并且可以准确地传达调用的状态。