HTTP 请求方法
HTTP 定义了一组请求方法，以表明要对给定资源执行的操作
指示针对给定资源要执行的期望动作
虽然他们也可以是名词，但这些请求方法有时被称为 HTTP 动词
介绍
| 简称 | 描述 | |
|---|---|---|
| GET | 获取资源 | 请求一个指定资源的表示形式，使用 GET 的请求应该只被用于获取数据 |
| POST | 创建子资源 | 用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用 |
| PUT | 更新资源 | 用请求有效载荷替换目标资源的所有当前表示 |
| DELETE | 删除文件 | 删除指定的资源 |
| PATCH | 部分更新 | 用于对资源应用部分修改 |
| HEAD | 获取报文首部 | 请求一个与 GET 请求的响应相同的响应，但没有响应体 |
| CONNECT | 要求用隧道协议连接代理 | 建立一个到由目标资源标识的服务器的隧道 |
| OPTIONS | 询问支持的方法 | 用于描述目标资源的通信选项 |
| TRACE | 追踪路径 | 沿着到目标资源的路径执行一个消息环回测试 |
对比
| 安全 | 幂等 | Request body | Response body | 可缓存 | 允许在 HTML表单中 | |
|---|---|---|---|---|---|---|
| GET | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ |
| POST | ❌ | ❌ | ✅ | ✅ | 仅当包含新鲜度信息时 | ✅ |
| PUT | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ |
| DELETE | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ |
| PATCH | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| HEAD | ✅ | ✅ | ❌ | ❌ | ✅ | ❌ |
| CONNECT | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ |
| OPTIONS | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
| TRACE | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
具体描述
GET
HTTP GET 方法请求指定的资源
使用 GET 的请求应该只用于获取数据
POST
HTTP POST 方法 发送数据给服务器。请求主体的类型由 Content-Type 首部指定。
PUT 和POST方法的区别是, PUT 方法是幂等的：连续调用一次或者多次的效果相同（无副作用）。连续调用同一个 POST 可能会带来额外的影响，比如多次提交订单。
一个 POST 请求通常是通过 HTML 表单发送, 并返回服务器的修改结果。在这种情况下, content type 是通过在 <form> 元素中设置正确的 enctype 属性，或是在 <input> 和 <button> 元素中设置 formenctype 属性来选择的:
- application/x-www-form-urlencoded: 数据被编码成以 '&' 分隔的键 - 值对，同时以 '=' 分隔键和值。非字母或数字的字符会被 percent-encoding: 这也就是为什么这种类型不支持二进制数据 (应使用 multipart/form-data 代替).
- multipart/form-data
- text/plain
当 POST 请求是通过除 HTML 表单之外的方式发送时，例如使用 XMLHttpRequest, 那么请求主体可以是任何类型。按 HTTP 1.1 规范中描述，POST 为了以统一的方法来涵盖以下功能：
注释已有的资源
在公告板，新闻组，邮件列表或类似的文章组中发布消息
通过注册新增用户
向数据处理程序提供一批数据，例如提交一个表单
通过追加操作，扩展数据库数据
PUT
HTTP PUT 请求方法使用请求中的负载创建或者替换目标资源
PUT 与 POST 方法的区别在于, PUT 方法是幂等的：调用一次与连续调用多次是等价的（即没有副作用），而连续调用多次 POST 方法可能会有副作用，比如将一个订单重复提交多次
DELETE
HTTP DELETE 请求方法用于删除指定的资源
PATCH
在 HTTP 协议中，请求方法 PATCH 用于对资源进行部分修改
在 HTTP 协议中， PUT 方法已经被用来表示对资源进行整体覆盖，而 POST 方法则没有对标准的补丁格式的提供支持。不同于 PUT 方法，而与 POST 方法类似, PATCH 方法是非幂等的，这就意味着连续多个的相同请求会产生不同的效果
要判断一台服务器是否支持 PATCH 方法，那么就看它是否将其添加到了响应首部 Allow 或者 Access-Control-Allow-Methods (在跨域访问的场合, CORS)的方法列表中
另外一个支持 PATCH 方法的隐含迹象是 Accept-Patch 首部的出现，这个首部明确了服务器端可以接受的补丁文件的格式
HEAD
HTTP HEAD 方法 请求资源的头部信息，并且这些头部与 HTTP GET 方法请求时返回的一致。该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载，以此可以节约带宽资源
HEAD 方法的响应不应包含响应正文。即使包含了正文也必须忽略掉。虽然描述正文信息的 entity headers, 例如 Content-Length 可能会包含在响应中，但它们并不是用来描述 HEAD 响应本身的，而是用来描述同样情况下的 GET 请求应该返回的响应
如果 HEAD 请求的结果显示在上一次 GET 请求后缓存的资源已经过期了, 即使没有发出GET请求, 缓存也会失效
CONNECT
在 HTTP 协议中, CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道 (tunnel)
例如, CONNECT 可以用来访问采用了 SSL (HTTPS) 协议的站点。客户端要求代理服务器将 TCP 连接作为通往目的主机隧道
之后该服务器会代替客户端与目的主机建立连接
连接建立好之后，代理服务器会面向客户端发送或接收 TCP 消息流
CONNECT 是一个应用范围为点到点的方法
OPTIONS
HTTP 的 OPTIONS 方法 用于获取目的资源所支持的通信选项
客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法
TRACE
HTTP TRACE 方法 实现沿通向目标资源的路径的消息环回 (loop-back)测试，提供了一种实用的 debug 机制
请求的最终接收者应当原样反射 (reflect) 它接收到的消息, 除了以下字段部分, 作为一个Content-Type 为 message/http 的 200 (OK)响应的消息的主体 (body)返回给客户端
最终接收者是指初始 (origin)服务器，或者第一个接收到 Max-Forwards 值为 0 的请求的服务器