请求方法，表明客户端希望服务器对资源执行的动作；
向服务器请求资源。
和GET方法的行为类似，但服务器在响应中只返回首部，不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。
可以做到：
不获取资源的情况下了解资源的情况(比如，判断器类型)
通过查看响应中的状态码，看看某个对象是否存在；
通过查看首部，测试资源是否被修改了；
与GET从服务器读取文件相反，PUT方法回向服务器写入文件。有些发布系统允许用户创建WEB页面，并用PUT直接将其安装到WEB服务器上；
PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命令的新文档，或者如果那个URL已经存在的话，就用这个主体来代替它；
因为PUT允许用户对内容进行修改，所以很多WEB服务器都要求在执行PUT之前，用密码登录。
向服务器发送要处理的数据；
一般服务器通常提供一个表单，客户端填入数据后点击提交(提交是数据都会放在请求报文的实体部分当中)，然后由服务器将其发送到它要去的地方（比如，送到一个服务器的网关程序中，然后由这个程序对其进行处理）；
客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE方法允许客户端在最终将请求发给服务器时，看看它变成了什么样子；
TRACE请求会在目的服务器发起一个“环回”针对。行程最后一站的服务器会弹出一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看所有中间HTTP应用程序组成的请求/响应链上，原始包文是否,以及如何被毁坏或修改过；
TRACE方法主要用于诊断；也就是说，用于验证请求是否如愿的穿过了请求/响应链。它是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生的效果。
尽管TRACE可以很方便的用于诊断，但是它确实也有缺点，它假定中间应用程序对各种不同类型请求（GET、HEAD、POST等）的处理是相同的。很多HTTP应用程序会根据方法的不同做出不同的事情，比如，代理可能会将POST请求直接发给服务器，而将GET请求发送给另一个HTTP应用程序（比如WEB缓存）。TRACE并不提供区分这些方法的机制。通常，中间应用程序会自行决定对TRACE请求的处理方式。
TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。 1.6 DELETE
DELETE方法所做的事情就是请求服务器删除请求URL所指定的资源。但是客户端应用程序无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。
1xx：100-101, （额外）信息提示类的状态码；
2xx：200-206, 成功类的状态码；
3xx：300-305, 重定向类的状态码；没有把请求的页面响应给客户端，而是重定向到其它地方，或是无需获取此资源；
4xx：400-415, 错误类信息，客户端的错误类的状态码；例如请求不存在的资源；
5xx：500-505, 错误类信息，服务器端错误类的状态码；例如服务器内部的问题，因为资源有语法错误运行部成功，无法响应，不是资源不存在；
200：OK
成功，请求的所有数据通过响应报文的entity-body部分发送；原因短语为OK；
201：Created
用于创建服务器对象的请求（比如，PUT）。响应实体主体部分中应该包含各种引用了已创建的资源的URL。Location首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象；