1. method

请求方法，表明客户端希望服务器对资源执行的动作；

1.1 get

向服务器请求资源。

1.2 head

和get方法的行为类似，但服务器在响应中只返回首部，不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。
可以做到：

不获取资源的情况下了解资源的情况(比如，判断器类型)
通过查看响应中的状态码，看看某个对象是否存在；
通过查看首部，测试资源是否被修改了；

1.3 put

与get从服务器读取文件相反，put方法回向服务器写入文件。有些发布系统允许用户创建web页面，并用put直接将其安装到web服务器上；
put方法的语义就是让服务器用请求的主体部分来创建一个由所请求的url命令的新文档，或者如果那个url已经存在的话，就用这个主体来代替它；
因为put允许用户对内容进行修改，所以很多web服务器都要求在执行put之前，用密码登录。

1.4 post

向服务器发送要处理的数据；
一般服务器通常提供一个表单，客户端填入数据后点击提交(提交是数据都会放在请求报文的实体部分当中)，然后由服务器将其发送到它要去的地方（比如，送到一个服务器的网关程序中，然后由这个程序对其进行处理）；

1.5 trace

客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的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规范允许服务器在不通知客户端的情况下撤销请求。

1.7 扩展方法

2 状态返回码

1xx：100-101, （额外）信息提示类的状态码；
2xx：200-206, 成功类的状态码；
3xx：300-305, 重定向类的状态码；没有把请求的页面响应给客户端，而是重定向到其它地方，或是无需获取此资源；
4xx：400-415, 错误类信息，客户端的错误类的状态码；例如请求不存在的资源；
5xx：500-505, 错误类信息，服务器端错误类的状态码；例如服务器内部的问题，因为资源有语法错误运行部成功，无法响应，不是资源不存在；

2.1 200~299--成功状态码

200：ok
成功，请求的所有数据通过响应报文的entity-body部分发送；原因短语为ok；

201：created
用于创建服务器对象的请求（比如，put）。响应实体主体部分中应该包含各种引用了已创建的资源的url。location首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象；

202：accepted
请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求；这只是意味着接受请求时，他看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置）；

203：non-authoritative information
实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的原信息（首部）进行验证，就会出现这种情况；
这种响应吗并不是非用不可的；如果实体首部来自源端服务器，相应为200状态的应用程序就可以将其作为一种可选项使用；

204：no content
响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面）；

205：rest content
另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有html表单元素；

206：partial content
成功执行了一个部分或range（范围）请求。客户端可以通过一些特殊的首部来获取部分或某个范围内的文档--这个状态码就说明范文请求成功了；
206相应中必须包含content-range、date以及etag或content-location首部；

2.2 300~399--重定向状态码

可以通过某些重定向状态码对浏览器本地缓存的资源副本与远端服务器上的资源进行验证。比如：用来查看本地的副本是否仍为最新的，或者远端服务器上的资源是否被修改过；
下图是客户端发送了一个特殊的if-modified-since首部，说明会读取1997年10月之后修改过的文档。因为这个日期之后，此文档并未修改过，因此，服务器回送了一个304状态码，而不是文档的内容；

300：multiple choices
客户端请求一个实际指向多个资源的url时就会返回这个状态码，比如服务器上有某个html文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择他希望使用的那一项了。

301：move permanently
请求的url指向的资源已经被删除（移动到其它位置）是永久重定向，资源被永久删除；但在响应报文中通过首部location指明了资源现在所处的新位置；原因短语为moved permanently；

302：found
与301相似，但在响应报文中通过location指明资源现在所处临时新位置，资源不是永久删除，是临时重定向; 原因短语为found；

303：see other
告知客户端应该用另一个url来获取资源。新的url位于响应报文的location首部。其主要目的是允许post请求的响应将客户端定向到某个资源上去；

304：not modified
客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过通过此响应状态码通知客户端（带有这个状态码的响应不应该包含实体的主体部分），客户端可继续使用本地网页缓存；原因短语为not modified；

305：use proxy
用来说明必须通过一个代理来访问资源；代理的位置有location首部给出。
很重要的一点是，客户端只是对某个特定资源来解析这条响应的；而不是对所有请求，甚至所有具有相同资源的服务器都通过这个代理进行；如果客户端错误的让代理介入了某个请求，可能会引发破坏性的行为，而且会造成安全漏洞；

306：未使用

307：temporary redirect
与301代码类似；但客户端应该使用location首部给出url来临时定位资源。将来的请求还使用老的url；

注意：
302、303、307状态码之间存在一些交叉。这些状态码的用法有细微的区别，大部分区别都源于http/1.0和http/1.1应用程序对这些状态码处理方式的不同。
当http/1.0客户端发起一个post请求，并在响应中收到302重定向状态码时，它会接受location首部的重定向url，并向那个url发起一个get请求（而不会向原始请求中那样发起post请求）。
http/1.0服务器希望http/1.0客户端这么做---如果http/1.0服务器收到来自http/1.0客户端的post请求之后发送了302状态码，服务器就期望客户端能够接受重定向url，并向重定向的url发送一个get请求；

问题出在http/1.1。http/1.1规范您使用了303状态码来实现同样的行为（服务器发送303状态码来重定向客户端的post请求，在它后面跟上一个get请求）。
为避开这个问题，http/1.1规范指出，对于http/1.1客户端，用307状态码取代302状态码来进行临时重定向。这样服务器就可以将302状态码保留起来，为http/1.0客户端使用。
这样一来，服务器要选择适当的重定向状态码放入重定向响应中发送，就需要查看客户端的http版本了。