每个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规范允许服务器在不通知客户端的情况下撤销请求