head，options和put的进一步了解

1.HEAD：HEAD和GET本质是一样的，区别在于HEAD不含有呈现数据，而仅仅是HTTP头信息。有的人可能觉得这个方法没什么用，其实不是这样的。想象一个业务情景：欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则意义更加明确。

# 请求
GET /hello HTTP/1.1
Host: localhost
# 响应
HTTP/1.1 200 OK
Content-Type: application/xml; charset=UTF-8
Content-Length: 21

2.OPTIONS：这个方法很有趣，但极少使用。它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。

　　其实还有一个TRACE方法，不过这个基本上不会用到，这里就不介绍了。

# 测试对应资源所支持的方法
OPTIONS /test-options HTTP/1.1
Host: localhost
# 响应
HTTP/1.1 204 No Content
Allow: GET, POST, OPTIONS

# ping服务器
OPTIONS * HTTP/1.1
Host: localhost
# 响应
HTTP/1.1 204 No Content

 

 

PUT：这个方法比较少见。HTML表单也不支持这个。本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。举个例子：如一个用于提交博文的URL，/addBlog。如果用PUT，则提交的URL会是像这样的”/addBlog/abc123”，其中abc123就是这个博文的地址。而如果用POST，则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。显然，PUT和POST用途是不一样的。具体用哪个还取决于当前的业务场景。

3.PUT

完整地更新或替换一个现有资源，也可以用客户端制定的URI来创建一个新资源。

• 请求：一个资源的表述。请求的body可以与客户端后续收到的GET请求一样,当然，也可以不一样。在某些情况下，服务器也可要求客户端只提供资源的可变部分。
• 响应：更新的状态。可在响应中包含被更新资源的完整表述，但是客户端不能假设响应中包含完整状态，除非响应有一个Content-Location头。如果服务器没有包含这个头，客户端必须提交一个无条件GET请求来获取更新后的表述，带有Last-Modified和/或ETag头。

# 更新资源的请求
PUT /stu/bob HTTP/1.1
Host: localhost
# 响应
HTTP/1.1 204 No Content

# 创建资源的请求
PUT /stu/alice HTTP/1.1
Host: localhost
# 响应
HTTP/1.1 201 Created
Location: http://localhost/stu/alice
Content-Length: 0