url 设计规范

什么是URI(URL)

定义:

名称	释义
URI	Uniform Resource Locators
URL	Uniform Resource Identicators

URI分两部分

scheme

scheme-specific

例：

http://write.blog.csdn.net/mdeditor

http为 schema，后面是schema-specific

schema 包括 HTTP,FTP,NEWS,GOPHER等

语法：
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要尽可能的短

根据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 )

提供动态
4000
内容服务时，应使用技术无关的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应当是统一的

附：

RFC1738网络标准

一般来说，URL只能使用英文字母、阿拉伯数字和某些标点符号，不能使用其他文字和符号。

比如，世界上有英文字母的网址 “http://www.abc.com”，但是没有希腊字母的网址“http://www.aβγ.com”（读作阿尔法-贝塔-伽玛.com）。

这是因为网络标准RFC 1738 做了硬性规定：

“…Only alphanumerics [0-9a-zA-Z], the special characters “$-_.+!*’(),” [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL.”

“只有字母和数字[0-9a-zA-Z]、一些特殊符号“$-_.+!*’(),”[不包括双引号]、以及某些保留字，才可以不经过编码直接用于 URL。”

这意味着，如果URL中有汉字，就必须编码后使用。但是麻烦的是，RFC 1738没有规定具体的编码方法，而是交给应用程序（浏览器）自己决定。这导致“URL编码”成为了一个混乱的领域。)