URL设计原则和规范

去年秋天写的一个文档,花了我两天时间.
转载请注明出处,谢谢:)
URI设计原则和规范
什么是URI(URL)
定义
URI:Uniform Resource Locators
URL:UniformResource 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上的虚拟目录
Symboliclinks，符号链接，Unix世界的符号链接
Table or database ofmappings，数据库映射，URI和文件系统结构的对应关系存储在数据库中
标准的重定向
管理员可以简单的通过修改HTTP状态代码来实现服务器文件系统结构变更之后的URI兼容，可以利用的HTTPStatus Code有：
301 Moved Permanently([RFC2616] section 10.3.2)
302 Found (undefined redirectscheme, [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和HTTPGET
总结
本文详细描述了URI的定义和作用，揭示了目前Web开发中普遍存在的问题，并给出了URI设计原则和规范，希望本文的读者能在开发和设计Web应用程序的时候体会和运用这些知识。
URI是Web UI的一部分，应当像对待网站Logo和公司品牌一样对待它
URI是网站和普通用户之间的唯一接口，应当像对待你的商务电话号码一样对待它
读懂并记住上面两句话，你下次设计URI的时候就会给它应有的重视了。
URL应当是用户友好的
URI应当是可读的
URI应当是可预测的
URI应当是统一的
读懂和记住上面四句话，你就知道应该设计什么样的URI了。