HTTP请求方法

请求方法是客户端发出的、要求服务器执行的、对资源的一种操作；

目前 HTTP/1.1 规定了八种方法，单词都必须是大写的形式

1. GET：获取资源，可以理解为读取或者下载数据；
2. HEAD：获取资源的元信息；
3. POST：向资源提交数据，相当于写入或上传数据；
4. PUT：类似 POST；
5. DELETE：删除资源；
6. CONNECT：建立特殊的连接隧道；
7. OPTIONS：列出可对资源实行的方法；
8. TRACE：追踪请求 - 响应的传输路径;

请求方法是对服务器的“指示”，真正应如何处理由服务器来决定；

GET 请求查看某文件时，服务器就可以有如下的几种响应方式：

1. 假装这个文件不存在，直接返回一个 404 Not found 报文；
2. 稍微友好一点，明确告诉你有这个文件，但不允许访问，返回一个 403 Forbidden；
3. 再宽松一些，返回 405 Method Not Allowed，然后用 Allow 头告诉你可以用 HEAD 方法获取文件的元信息。

GET

请求从服务器获取资源
搭配 URI 和其他头字段就能实现对资源更精细的操作。

• 在 URI 后使用“#”，就可以在获取页面后直接定位到某个标签所在的位置；
• 使用 If-Modified-Since 字段就变成了“有条件的请求”，仅当资源被修改时才会执行获取动作；
• 使用 Range 字段就是“范围请求”，只获取资源的一部分数据。

HEAD

请求从服务器获取资源，不会返回请求的实体数据，只会传回响应头，也就是资源的“元信息”。

应用场景：

• 检查一个文件是否存在。
• 检查文件是否有最新版本，同样也应该用 HEAD，服务器会在响应头里把文件的修改时间传回来。

POST/PUT

向 URI 指定的资源提交数据，数据就放在报文的 body 里。

通常 POST 表示的是“新建”“create”的含义，而 PUT 则是“修改”“update”的含义。

DELETE

指示服务器删除资源，因为这个动作危险性太大，所以通常服务器不会执行真正的删除操作，而是对资源做一个删除标记。当然，更多的时候服务器就直接不处理 DELETE 请求。

CONNECT

要求服务器为客户端和另一台远程服务器建立一条特殊的连接隧道，这时 Web 服务器在中间充当了代理的角色。

OPTIONS

要求服务器列出可对资源实行的操作方法，在响应头的 Allow 字段里返回。

TRACE

TRACE 方法多用于对 HTTP 链路的测试或诊断，可以显示出请求 - 响应的传输路径。它的本意是好的，但存在漏洞，会泄漏网站的信息，所以 Web 服务器通常也是禁止使用。

扩展方法

安全与幂等

在 HTTP 协议里，所谓的“安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。

按照这个定义，只有 GET 和 HEAD 方法是“安全”的，因为它们是“只读”操作，只要服务器不故意曲解请求方法的处理方式，无论 GET 和 HEAD 操作多少次，服务器上的数据都是“安全的”。
而 POST/PUT/DELETE 操作会修改服务器上的资源，增加或删除数据，所以是“不安全”的。

所谓的“幂等”实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。

GET 和 HEAD 既是安全的也是幂等的，DELETE 可以多次删除同一个资源，效果都是“资源不存在”，所以也是幂等的。
按照 RFC 里的语义，POST 是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；而 PUT 是“替换或更新数据”，多次更新一个资源，资源还是会第一次更新的状态，所以是幂等的。