什么是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 )提供动态内容服务时,应使用技术无关的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编码”成为了一个混乱的领域。)