HTTP 方法用于指示 API 客户端希望对给定资源执行的操作。每个 HTTP 方法都对应一个特定的操作，例如创建、读取、更新或删除资源，并且每个对 REST API 的请求都必须包含 HTTP 方法。

HTTP 协议的工作原理是客户端向服务器发送请求，服务器响应这些请求。我们通过使用不同 HTTP 方法（有时称为 HTTP 动词）发送 HTTP 请求来执行 CRUD 操作（创建、读取、更新、删除）。GET 和 POST 是最常用的 HTTP 方法，但还有更多 HTTP 方法需要学习。本文将介绍不同的 HTTP 方法以及在构建和使用 Web API 时如何使用它们。

您应该了解的 9 种 HTTP 方法

1. GET 方法

如果我们想从资源（如网站、服务器或 API）检索数据，我们会向它们发送 GET 请求。例如，如果我们想要客户列表或特定客户，我们会向服务器发送 GET 请求。

由于 GET 方法不应该更改资源上的数据，而只是读取它们（只读），因此它被认为是安全方法。此外，GET 方法是幂等的。

如何使用 GET 方法测试 API？

当我们想要测试 API 时，我们最常用的方法是 GET 方法。因此，我们期望发生以下情况：

如果资源可访问，API 将返回 200 状态代码，表示“OK”。

除了 200 状态代码外，服务器通常还会返回 XML 或 JSON 格式的响应正文。例如，我们期望 [/members] 端点返回 XML 或 JSON 格式的成员列表。

如果服务器不支持该端点，则服务器将返回 404 状态代码，表示“未找到”。

如果我们以错误的语法发送请求，服务器将返回 400 状态代码，表示“错误请求”。

2. POST 方法

POST 方法在后端（服务器）创建新的资源。请求正文承载我们想要发送到服务器的数据。它既不是安全方法也不是幂等方法。我们不期望每次发送 POST 请求都能获得相同的结果。例如，两个相同的 POST 请求将创建两个具有相同数据和不同资源 ID 的新的等效资源。

向服务器发送 POST 请求时，我们期望发生以下情况：

理想情况下，如果 POST 请求在另一端创建了一个新的资源，则响应应该带有 201 状态代码，表示“已创建”。

有时，执行 POST 请求不会在给定的 URL 返回资源；在这种情况下，该方法将返回 204 状态代码，表示“无内容”。

如何测试 POST 端点

由于 POST 方法创建数据，我们必须谨慎更改数据；强烈建议测试 API 中的所有 POST 方法。此外，请确保在测试完成后删除已创建的资源。

以下是一些我们可以用来测试使用 POST 方法的 API 的建议：

使用 POST 方法创建一个资源，它应该返回 201 状态代码。

执行 GET 方法以检查是否成功创建了资源。您应该获得 200 状态代码，并且响应应该包含已创建的资源。

使用不正确或格式错误的数据执行 POST 方法以检查操作是否失败。

3. PUT 方法

使用 PUT 请求方法，我们可以通过将更新后的数据作为请求正文的内容发送到服务器来更新现有资源。PUT 方法通过完全替换其全部内容来更新资源。如果它应用于资源集合，它将替换整个集合，因此请小心使用它。服务器在成功更新现有资源后将返回 200 或 204 状态代码。

如何使用 PUT 方法测试 API？

PUT 方法是幂等的，它修改整个资源，因此为了测试该行为，我们确保执行以下操作：

多次向服务器发送 PUT 请求，它应该始终返回相同的结果。

当服务器完成 PUT 请求并更新资源时，响应应该带有 200 或 204 状态代码。

服务器完成 PUT 请求后，发出 GET 请求以检查资源上的数据是否已正确更新。

如果输入无效或格式错误，则不得更新资源。

4. PATCH 方法

PATCH 是另一种不常用的 HTTP 方法。与 PUT 类似，PATCH 更新资源，但它仅部分更新数据，而不是全部更新。例如，为了更精确起见，请求 [PUT] customers/{customerid} 将完全更新资源上 Customers 实体中的字段。但是，PATCH 方法确实会更新客户实体的提供的字段。通常，此修改应采用标准格式，例如 JSON 或 XML。

如何使用 PATCH 方法测试 API？

要使用 PATCH 方法测试 API，请按照本文中讨论的步骤进行操作，以使用 PUT 和 POST 方法测试 API。考虑以下结果：

向服务器发送 PATCH 请求；服务器将返回 2xx HTTP 状态代码，这意味着：请求已成功接收、理解和接受。

执行 GET 请求并验证内容是否已正确更新。

如果请求有效负载不正确或格式错误，则操作必须失败。

5. DELETE 方法

顾名思义，DELETE 方法删除资源。DELETE 方法是幂等的；无论调用次数多少，它都返回相同的结果。

大多数 API 总是返回 200 状态代码，即使我们尝试删除已删除的资源也是如此，但在某些 API 中，如果目标数据不再存在，则方法调用将返回 404 状态代码。

如何测试 DELETE 端点？

在服务器上删除某些内容时，我们应该谨慎。我们正在删除数据，这至关重要。首先，确保删除数据是可以接受的，然后执行以下操作：

调用 POST 方法以创建新的资源。切勿使用实际数据测试 DELETE。例如，首先创建一个新客户，然后尝试删除您刚刚创建的客户。

对特定资源发出 DELETE 请求。例如，请求 [DELETE] /customers/{customer-id} 删除具有指定客户 ID 的客户。

对已删除的客户调用 GET 方法，它应该返回 404，因为资源不再存在。

6. HEAD 方法

HEAD 方法类似于 GET 方法。但它没有任何响应正文，因此如果它错误地返回响应正文，则必须忽略它。例如，[GET] /customers 端点在其响应正文中返回客户列表。此外，[HEAD] /customers 也执行相同的操作，但它不返回客户列表。在请求 GET 端点之前，我们可以发出 HEAD 请求以确定我们正在下载的文件或数据的大小（Content-length）。因此，HEAD 方法是安全且幂等的。

如何测试 HEAD 端点

HEAD 方法的优点之一是，只要 API 支持它，我们就可以测试服务器是否可用和可访问，并且它比 GET 方法快得多，因为它没有响应正文。我们期望从 API 获取的状态代码是 200。在每种其他 HTTP 方法之前，我们都可以先使用 HEAD 方法测试 API。

7. OPTIONS 方法

我们使用此方法来获取有关服务器中给定 URL 的可能的通信选项（允许的 HTTP 方法）的信息，或者使用星号来指代整个服务器。此方法是安全且幂等的。

各种浏览器广泛使用 OPTIONS 方法来检查目标 API 上的 CORS（跨源资源共享）操作是否受限。

如何测试 OPTIONS 端点

根据服务器是否支持 OPTIONS 方法，我们可以使用 OPTIONS 方法测试服务器的致命故障次数。要尝试它，请考虑以下几点：

发出 OPTIONS 请求并检查返回的标头和状态代码。

测试使用不支持 OPTIONS 方法的资源的失败情况。

8. TRACE 方法

TRACE 方法用于诊断目的。它使用与客户端之前发送到服务器的请求正文相同的请求正文创建一个环回测试，并且成功的响应代码是 200 OK。TRACE 方法是安全且幂等的。

TRACE 方法可能很危险，因为它可能会泄露凭据。黑客可以使用客户端攻击窃取凭据，包括内部身份验证标头。

如何使用 TRACE 方法测试 API？

发出标准 HTTP 请求，例如对 /api/status 的 GET 请求

将 GET 替换为 TRACE 并再次发送。

检查服务器返回的内容。如果响应与原始请求具有相同的信息，则服务器中启用了 TRACE 功能并且工作正常。

9. CONNECT 方法

CONNECT 方法用于在客户端和服务器之间建立端到端连接。它在它们之间建立双向连接，就像隧道一样。例如，我们可以使用此方法在客户端和服务器之间安全地传输大型文件。

HTTP 方法比较

方法 摘要 CRUD 接受请求正文 幂等 安全 GET 获取单个资源或资源组 读取 否 是 是 PUT 一次性更新整个资源 更新 是 是 否 POST 创建新资源 创建 是 否 否 PATCH 部分更新资源 更新 是 否 否 DELETE 删除资源 删除 否 是 否 OPTIONS 获取有关允许的操作的信息 读取 否 是 是 HEAD 获取端点的元数据 读取 否 是 是 TRACE 用于诊断目的 读取 否 是 是 CONNECT 在客户端和资源之间建立双向连接 - 否 - -