URI与URL的区别

URL与URI区别:

(零)区别与联系:
(1)URI,是uniform resource identifier,统一资源标识符,用来唯一的标识一个资源。而URL是uniform resource locator,统一资源定位器,它是一种具体的URI,即URL可以用来标识一个资源,而且还指明了如何locate这个资源。而URN,uniform resource name,统一资源命名,是通过名字来标识资源,比如mailto:java-net@java.sun.com。也就是说,URI是以一种抽象的,高层次概念定义统一资源标识,而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。
(2)在Java的URI中,一个URI实例可以代表绝对的,也可以是相对的,只要它符合URI的语法规则。而URL类则不仅符合语义,还包含了定位该资源的信息,因此它不能是相对的,schema必须被指定。


(3)到底是imgUrl好呢,还是imgUri好?显然,如果说imgUri是肯定没问题的,因为即使它实际上是url,那它也是uri的一种。那么用imgUrl有没有问题呢?此时则要看它的可能取值,如果是绝对路径,能够定位的,那么用imgUrl是没问题的,而如果是相对路径,那还是不要用ImgUrl的好。总之,用imgUri是肯定没问题的,而用imgUrl则要视实际情况而定。


(4)从HttpServletRequest的javadoc中可以看出,getRequestURI返回一个String,“the part of this request’s URL from the protocol name up to the query string in the first line of the HTTP request”,比如“POST /some/path.html?a=b HTTP/1.1”,则返回的值为”/some/path.html”。现在可以明白为什么是getRequestURI而不是getRequestURL了,因为此处返回的是相对的路径。而getRequestURL返回一个StringBuffer,“The returned URL contains a protocol, server name, port number, and server path, but it does not include query string parameters.”,完整的请求资源路径,不包括querystring。


(5)总结:
总结一下:URL是一种具体的URI,它不仅唯一标识资源,而且还提供了定位该资源的信息。URI是一种语义上的抽象概念,可以是绝对的,也可以是相对的,而URL则必须提供足够的信息来定位,所以,是绝对的,而通常说的relative URL,则是针对另一个absolute URL,本质上还是绝对的。
注:这里的绝对(absolute)是指包含scheme,而相对(relative)则不包含scheme。


(一)统一资源定位符:URL(uniform resource location):


(1)URL的使用:
URL是Internet上用来描述信息资源的字符串,主要用在各种WWW客户程序和服务器程序上。采用URL可以用一种统一的格式来描述各种信息资源,包括文件、服务器的地址和目录等。
(2)URL的组成:
URL的格式由下列三部分组成:
1.协议(或称为服务方式);
2.存有该资源的主机IP地址(有时也包括端口号);
3.主机资源的具体地址。如目录和文件名等。


  第一部分和第二部分之间用”://”符号隔开,第二部分和第三部分用”/”符号隔开。第一部分和第二部分是不可缺少的,第三部分有时可以省略。


  目前最大的缺点是当信息资源的存放地点发生变化时,必须对URL作相应的改变。因此人们正在研究新的信息资源表示方法。


---------


(二)统一资源标识符:URI(uniform resource identifier):


(0)URI结构:


URI抽象结构     [scheme:]scheme-specific-part[#fragment]


[scheme:][//authority][path][?query][#fragment]


authority为[user-info@]host[:port]


(1)URI组成:
URI是以某种统一的(标准化的)方式标识资源的简单字符串,一般由三部分组成:
1.访问资源的命名机制。
2.存放资源的主机名。
3.资源自身的名称,由路径表示。


(2)URI的典型情况与特殊情况:


典型情况下,这种字符串以scheme开头,语法如下:


  [scheme:] scheme-specific-part


  http://www.google.com,其中http是scheme,//www.google.com是 scheme-specific-part,并且它的scheme与scheme-specific-part被冒号分开了。


有的URI指向一个资源的内部。这种URI以”#”结束,并跟着一个anchor标志符(称为片断标志符)。


  相对URI不包含任何命名规范信息。它的路径通常指同一台机器上的资源。相对URI可能含有相对路径(如:“..”表示上一层路径),还可以包含片断标志符。


(3)选择URI规则:


 URI 是网站UI的一部分,因此,可用的网站应该满足这些URL 要求
•简单,好记的域名
•简短(short)的URI
•容易录入的URI
•URI 能反应站点的结构
•URI 是可以被用户猜测和hack的(也鼓励用户如此)
•永久链接,Cool URI don’t change


  聪明的选择URI


  一定要短 为了URI能被方便的录入,写下,拼写和记忆,URI 要尽可能的短,根据w3c 提供的参考数据,一个URI 的长度最好不要超过80个字节(这并非一个技术限制,经验和统计提供的数据),包括schema 和host,port 等。


   大小写策略 URI的大小写策略要适当,要么全部小写,要么首字母大写,应避免混乱的大小写组合,在Unix 世界,文件路径队大小写是敏感的,而在Windows 世界,则不对大小写敏感。


   允许URI管理 URI映射 管理员可以重新组织服务器上的文件系统结构,而无需改动URI,这就需要URI和真实的服务器文件系统结构之间有一个映射机制。,而不是生硬的对应。这种映射机制可以通过如下技术手段实现:
•Aliases ,别名,Apache 上的目录别名,IIS 上的虚拟目录
•Symbolic links ,符号链接,Unix 世界的符号链接
•Table or database of mappings ,数据库映射,URI 和文件系统结构的对应关系存储在数据库中。


  标准的重定向 管理员可以简单的通过修改HTTP 状态代码来实现服务器文件系统结构变更之后的URI兼容,可以利用的HTTP Status Code 有:
•301 Moved Permanently ([RFC2616] section 10.3.2)
•302 Found (undefined redirect scheme, [RFC2616] Section 10.3.3)
•Temporary Redirect ([RFC2616] Section 10.3.8)


  用独立的URI


  技术无关的URI
•提供动态内容服务时,应使用技术无关的URI。即URI不暴露服务器端使用的脚本语言,平台引擎,而这些语言,平台,引擎的变化也不会导致URI的变更。因此,sevelet,cgi-bin之类的单词不应该出现在URI 中。
•提供静态内容服务时,应当隐去文件的扩展名取而代之的技术是content-negotiation, proxy, 和URI mapping


  身份标志和Session 机制
•使用标准的身份认证机制,而不是每个用户一个特定的URI
•使用标准的Session 机制,而不是把Session ID 放在URI 中使用。


  内容变更时使用标准转向
•对变更的内容使用标准的重定向
•对删除的资源使用 HTTP410


  提供索引代理


  索引策略
•Content-Location
•Content-MD5


  提供适当的缓存信息
•缓存相关的HTTP头
•缓存策略
•缓存生成内容 HTTP HEAD和HTTP GET


  总结
•URI 是Web UI 的一部分,应当像对待网站Logo 和公司品牌一样对待它
•URI 是网站和普通用户之间的唯一接口,应当像对待你的商务电话号码一样对待它


  读懂并记住上面两句话,你下次设计URI 的时候就会给它应有的重视了。
•URL 应当是用户友好的
•URI 应当是可读的
•URI 应当是可预测的
•URI 应当是统一的


  读懂和记住上面四句话,你就知道应该设计什么样的URI了


---------


(三)统一资源名称:URN(uniform resource name):
阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页