SoapUI RESTful - HTTP 方法

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

POST

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

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

创建成功后，返回 HTTP 状态码 201，并返回包含指向新创建资源链接的 location 头部（与 201 HTTP 状态码一起）。

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

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

GET

HTTP GET 方法用于读取或检索资源的表示。在成功响应中，GET 返回 XML 或 JSON 格式的表示以及 HTTP 响应代码 200（OK）。在错误情况下，它通常返回 404（NOT FOUND）或 400（BAD REQUEST）。

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

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

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

PUT

PUT 用于更新现有资源。PUT 使用已知的资源 URI，以及请求体中包含原始资源更新表示的请求。

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

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

如果 PUT 用于创建，则在成功创建后返回 HTTP 状态码 201。响应中的主体是可选的。

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

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

PATCH

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

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

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

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

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

DELETE

DELETE 用于删除由 URI 标识的资源。成功删除后，它返回 HTTP 状态码 200 (OK) 和响应主体，即已删除项目的表示。否则，它返回 HTTP 状态码 204 (NO CONTENT)，没有响应主体。

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

从 HTTP 规范来看，DELETE 操作是幂等的。如果用户删除资源，则该资源将被删除。重复对同一资源调用 DELETE 的结果相同：资源消失了。

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