URL设计原则和规范

ekylin 2007-05-26

展开全文

URL设计原则和规范

去年秋天写的一个文档,花了我两天时间.
转载请注明出处,谢谢:)

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./PR/announcements/1994/dec/new-server-version.txt

这个还算好的，看看这个：http://www./servlet/ArticleNews/PEstory/TGAM/20020909/RVCRR/Business/business/business_temp/2/2/5/

莫明其妙的大写字母

比如：

ftp://ftp./pub/docs/OnTBGHill.txt

不常见的标点符号

ftp://ftp./pub/docs/moon_3+manual

在纸介质上显示很困难

一些字符在纸上打印出来不容易辨认，例如

“～”（数字键1旁边那个键）在不同的字体下面显示不同，有时候在一行的顶部，有时候在底部。

“l”（字母L的小写版本）和“1”（数字一）几乎无法分辨——在纸介质上的时候，同样的还有“O”和“0”。

“`”太微小，以致于人们在某些情况下看不到它。

主机和端口的问题

除了 scheme-specific 部分，domain和port也可能给用户带来困惑。

http://admin.: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./FOO和http://www./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