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了。