每个Web服务器资源都有一个名字，这样客户端就可以说明他们感兴趣的资源是什么了，服务器资
源名被统称为：统一资源标识符(Uniform Resource Identifier, URI)
Joe的五金店的Web服务器上一个图片资源的URI：
http://www.joes-hardware.com/specials/saw-blade.gif
URI有两种形式，分别为URL和URN，URN仍然处于试验阶段，因此现在所说的URI就是指URL
URL精确地说明了某资源的位置以及如何去访问它，获取资源过程如下：
1：使用HTTP协议，2:进入www.joes-hardware.com主机，3：获取名为/specials/saw-
blade.gif的资源
请求方法
GET ：用于请求服务器发送某个资源
HEAD: 与GET方法类似，但服务器在响应中只返回首部，不会返回实体的主题部分
PUT：向服务器写入文档
PUT方法的语意就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，或者
如果那个URL已经存在的话，就用这个主体来代替它
POST：POST方法起初是用来向服务器输入数据，实际上通常会用它来支持HTML的表单，
表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方(比如送到一个服
务器网关程序中，然后由这个程序对其进行处理)
注意：POST用于向服务器发送数据，PUT用于向服务器上的资源(例如文件)中存储数据
TRACE：客户端发起一个请求时，这个请求可能要穿过防火墙，代理，网关或其他一些应用
程序，每个节点都可能修改原始的HTTP请求，TRACE方法允许客户端在最终将请求发送给服务
器时，看看它变成了什么样子
TRACE请求会在目的服务器端发起一个“环回”诊断，行程最后一站的服务器会弹回一条TRACE响
应，并在相应主体中携带它收到的原始请求报文，这样客户端就可以查看在所有中间HTTP应用程
序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改过
TRACE方法主要用于诊断，验证请求是否如愿穿过了请求/响应链，它是一种很好的工具，可以
用来查看代理和其他应用程序对用户请求所产生的效果
尽管TRACE可以方便用于诊断，它的缺点在于它假定中间应用程序对各种不同类型请求(不同方
法--GET,HEAD,POST等)的处理是相同的，很多HTTP应用程序会根据方法的不同做出不同的处
理，比如，代理可能将POST请求直接发送给服务器，而将GET发送给另一个HTTP应用程序(比
如Web缓存),TRACE并不提供区分这些方法的机制，通常中间应用程序会自行决定对TRACE请求
的处理方式
TRACE请求中不能带有实体的主体部分，TRACE响应的实体主体部分包含了响应服务器收到的请
求的精确副本
OPTIONS：请求服务器告知其支持的各种功能，可以询问服务器通常支持哪些方法，或者对
某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操作),这
为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判断访问各资源的最优方式
DELETE：请求服务器删除URL所指定的资源，但是客户端应用程序无法保证输出操作一定会被执行，因为HTTP规范允许服务器在不通知客户端的情况下撤销请求