HTTP 支持的方法 （GET、POST 和 PUT 区别、HEAD、DELETE、OPTIONS、TRACE、 CONNECT）

HTTP 支持的方法有

主要方法	功能说明
GET	获取资源
POST	传输实体主体，一般用于向服务器提交数据
PUT	传输文件
HEAD	获取报文首部
DELETE	删除文件
OPTIONS	询问服务器支持的方法
TRACE	追踪路径
CONNECT	要求用隧道协议连接

HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。

CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

• GET
  GET 想要检索一个资源，无论是资源的集合，还是单个站点（site/1208）。
• POST
  POST 表示添加新资源，或者你可以将其视为创建资源。
• PUT
  PUT 表示更新现有资源，因此要使用具有可能已更改的信息的资源并对其进行更新以反映新数据。
• PATCH
  PATCH 与 PUT 非常相似，只是它使用某些数据来更新资源。你可以只发送一部分对象，而不是使用 PUT 发送整个对象。你可以想象在我们的示例中，我们可以发送一个位置来修补有关站点内部位置的信息。
• DELETE
  DELETE 删除现有资源。这个你可能更熟悉吧，那就是著名的删库跑路。

更具体地说，动词与 URI 一起使用时应该做什么？假设我们有一个资源，就是我们的用户，也就是 /customers：

• 如果发出 GET 请求，则应该返回这些客户的列表。
• 如果我们发出 POST，则应该创建一个新客户。
• 如果我们对作为集合的端点执行 PUT，则我希望 PUT 可以一次更新一堆客户。请记住，客户的 URI 代表的是客户的完整集合，而不是单个客户。
• 如果发出 DELETE 的请求。可能会出错，这表示要删除该客户集合，因为你可能找不到删除整个集合的用例。除非是删库跑路，如果设计的好的话，删库跑路应该是不存在的，或者说几率非常低的。

现在，这已满足你系统的要求，在这种情况下，你可能会发现一些子对象，例如删除特定客户的所有预约还是有可能，但是你很少想要在你的顶级资源上执行此操作。也就是删除所有客户的所有预约。

当我们处理这些集合中的单个项目时比如 /customers/chris，这些动词会做不同的事情。对于特定客户：

• GET 应该只返回该客户。就像我们在 Postman 中看到的一样。
• 对该集合执行 POST 没有任何意义，因此它应该返回错误，因为你无法创建已经创建的对象。这就是为什么你通常将 POST 发送到集合。POST 是关于创建新客户的，因此在该客户内部创建新客户是没有意义的。
• PUT 将更新单个客户。
• DELETE 应该删除该客户。

除了我们上面讲的那四个之外，还有以下 5 个。

• HEAD
  和 GET 相似，只不过我不要你响应的 body，我只要你的头信息。就是我只看你的脸，不管你的身材。
• CONNET
  CONNECT：CONNECT 方法启动与请求资源的双向通信。可以用来打开隧道。例如，CONNECT 方法可用于访问使用 SSL（HTTPS）的网站。客户端要求 HTTP 代理服务器通过隧道将 TCP 连接到所需的目的地。然后服务器继续代表客户端建立连接。服务器建立连接后，代理服务器将继续代理与客户端之间的 TCP 流。这个不太常用。
• OPTIONS
  OPTIONS 用于描述目标资源的通信选项。
• TRACE
  TRACE 沿着目标资源的路径执行消息环回测试。
• PATCH
  PATCH 用于对资源应用部分修改。比如说你的资料，对吧，包括你姓名、年龄、婚姻、地址等等，但是你搬家了，你需要重新生成一个新的资料吗？不需要吧，你只是需要更新一下地址就好。

我相信这时候，很多人会问 PUT 和 POST 一样，那怎么区分什么时候使用呢？

PUT 和 POST 的区别在于 PUT 是幂等的。

什么叫作幂等？幂等就是连续调用一次或多次具有相同的效果（即没有副作用），而连续相同的 POST 请求可能具有额外的效果，类似于多次下订单，但是 PUT 却不会。

让我们从 URI 开始讨论。在 REST 中，URI 只是资源的路径。因此，当你拥有服务器时，就会有一个 API，它就是服务器名称后的任何路径，以指示如何获取该服务器上的某个对象。比如 api.diaozhatian.com/people，在设计 API 时我们不会考虑的 URI 的一部分通常是查询字符串。

因此，可以将其添加到 URI 末尾。当从逻辑上考虑查询字符串时，查询字符串应该始终是可选的。它们通常用于格式化，排序和搜索之类的事情。因此，在设计 API 时，我希望你考虑名词。这点很重要，一定要记住。名词是大大的好，动词是大大的不好。这里有一些例子。在我构建 API 的早期，我很容易将 API 视为只是一些远程过程调用的端点。因此，下面这些例子，看上去都是有道理的。

但是在 REST API 中，我们实际更喜欢名词或者说更应该使用名词。比如下面这样。

幂等性概念：

它只是意味着一个操作（如果多次执行）应该执行相同的操作。如果我们看一个示例，你执行的操作应具有相同的副作用（如果有）。对于 GET、PUT、PATCH 和 DELETE，无论如何，它都应执行相同的操作。

DELETE 应该删除某个资源或返回错误。假设系统中没有任何变化，则 GET 应该始终返回相同的数据。如果有必要，PUT 应该继续进行相同的更改。如果你连续两次或三次发出 PUT 或 PATCH，则不应该因为没有更改而使第二或第三次失败，它应该可以正常工作。

一个重要的例外是 POST。POST 永远不是幂等的。你应该假设每次 POST 到 API 都会返回一个全新的对象，因此在 POST 的情况下不必担心幂等性。接下来让我们看看幂等的含义。

让我们通过 API 来了解幂等性是什么意思。我们每次上网都是通过 GET 网站的内容来拿到网页的信息，然后对他进行浏览。如果我针对站点发出 GET 请求，则它每次都应该返回相同的信息或者说集合，并且每次都应以相同的顺序返回。

当我发送 PUT 相同内容的时候，返回的是 No changes detected。实际上，这不是 API 应该做的事情。它应该总是去尝试进行更新，并且如果在该更新中未检测到任何更改，则应像发生此更新一样进行操作。它不应返回这样的错误信息。这违反了幂等性。这种设计是错误的，你一定要记住在你的设计中，不要这样做。这不是好的设计。