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):