URI设计原则和规范
什么是URI(URL)
定义
URI: Uniform Resource Locators
URL:Uniform Resource Identicators
URI 分两部分，scheme, scheme-specific ，这两部分由冒号分割开。schema 包括HTTP,FTP,NEWS,GOPHER 等，详情参见RFC1738 （ftp://ds.internic.net/rfc/rfc1738.txt ）
语法
HTTP,FTP 的语法很相像，都是这样:
schema://user:password@host:port/directory/file.extension
编码
URI 中理论上只允许ASCII 字符。
部分特殊符号必须编码，不能直接出现在URI 中，如“~”
Web 项目中，这些都是URI ：
链接地址（a 标签的href 属性）
图片的源（img 标签的src 属性）
多媒体文件的源（object 标签的src 属性）
CSS ，JavaScript 地址（link 标签的href 属性，script 标签的src 属性）
为什么要设计好的URI
重要的入口
便于传播
便于用户挖掘内容
URI 的常见问题
难以输入
URI 不必要的冗长
比如：
http://www.bigcompany.com/PR/announcements/1994/dec/new-server-version.txt
这个还算好的，看看这个：http://www.globeandmail.com/servlet/ArticleNews/PEstory/TGAM/20020909/RVCRR/Business/business/business_temp/2/2/5/
莫明其妙的大写字母
比如：
ftp://ftp.bigstate.edu/pub/docs/OnTBGHill.txt
不常见的标点符号
ftp://ftp.bigstate.edu/pub/docs/moon_3+manual
在纸介质上显示很困难
一些字符在纸上打印出来不容易辨认，例如
“～”（数字键1 旁边那个键）在不同的字体下面显示不同，有时候在一行的顶部，有时候在底部。
“l” （字母L 的小写版本）和“1” （数字一）几乎无法分辨——在纸介质上的时候，同样的还有“O” 和“0” 。
“`” 太微小，以致于人们在某些情况下看不到它。
主机和端口的问题
除了 scheme-specific 部分，domain 和port 也可能给用户带来困惑。
http://admin.bigstate.edu:8001/docs/thesis/jones
设计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 世界，则不对大小写敏感，所以，http://www.example.com/FOO 和http://www.example.com/foo 是两个不同的URI （尽管他们在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 中
使用Tomcat 和PHP3 的站点容易犯这类错误，将Session ID 放在URI 中，实际上，他们应当用HTTP Header 来实现之。
内容变更时使用标准转向
对变更的内容使用标准的重定向
对删除的资源使用HTTP410
提供索引代理
索引策略
Content-Location
Content-MD5
提供适当的缓存信息
缓存相关的HTTP 头
缓存策略
缓存生成内容
HTTP HEAD 和HTTP GET
总结
本文详细描述了URI 的定义和作用，揭示了目前Web 开发中普遍存在的问题，并给出了URI 设计原则和规范，希望本文的读者能在开发和设计Web 应用程序的时候体会和运用这些知识。
-
URI 是Web UI 的一部分，应当像对待网站Logo 和公司品牌一样对待它
-
URI 是网站和普通用户之间的唯一接口，应当像对待你的商务电话号码一样对待它
读懂并记住上面两句话，你下次设计URI 的时候就会给它应有的重视了。
-
URL 应当是用户友好的
-
URI 应当是可读的
-
URI 应当是可预测的
-
URI 应当是统一的
读懂和记住上面四句话，你就知道应该设计什么样的URI 了。