理解URI,URL,URN

Posted 2021-01-01 redreampt

在Web领域，我们常见三个专业词汇URI,URL,URN，对于这三个词我们或许知道其原意，其相互之间的关系，但对于URI,URN总有那么一层朦胧感，因为URI是抽象的概念，而URN远离现实开发有关。在这里对这3个概念进行一些分析，试图理清其内在逻辑。

首先需要了解IETF,RFC

在了解上述3个专业名词前，我们需要先了解IETF和RFC，因为这两者定义了UR*。IETF是国际互联网工程任务组（The Internet Engineering Task Force），它是互联网技术标准化的国际民间组织。RFC是提交请求（Request For Comments），是一系列以编号排定的文件。RFC文档可分为三种：

• BCP Best Current Practice，最佳实践。
• FYI For Your Information，信息文档，仅供讨论。
• STD Standard， 标准文档。

IETF是定义URI,URL,URN的组织，RFC是定义URI,URL,URN的标准文件。

参考：
RFC2026 https://datatracker.ietf.org/doc/rfc2026/
RFC wiki https://zh.wikipedia.org/wiki/RFC

URL

URL是统一资源定位符的缩写，它对网络中的资源的定位提供了一种统一方案。它有如下的通用格式：

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<fragment>

URL是我们最常见，开发过程中也时时刻刻能接触到的概念。也就是如上格式的表示网络资源的地址的字符串。此外还有相对URL，这里就不细述了。
类比于现实中的地址，URL就是Web中资源地址。

参考：
URL定义 RFC1738 https://www.w3.org/Addressing/rfc1738.txt
URL讲解 URL与资源《html权威指南》第二章

URN

URN是统一资源名称的缩写，它对网络中的资源的名称提供了一种统一方案。它要求全球唯一，并在资源不存在或不再可用时依然保持不变。它的格式如下：

"urn:" <NID> ":" <NSS>

URN基于这样一种想法，网络中的URL是不会持久的，就像人可能搬家一样，网络资源也可能被移动，导致URL失效。其基本思想是引入持久层URN，就像人一生基本不会改名，这样就能避免URL的失效问题。URN采取某些策略实现URN与实际资源的映射，但这里不用考虑。

20多年过去URN似乎并没实用价值，这是很正常的，技术发展中很多技术标准都沉默于历史中。但并不意味着其一定没有价值，就像Web开发早期流行SOAP，后来回归到HTTP原始语义的RESTful。目前需要理解URN是因为其与URL,URI是绑定关系，因此必须知其所以然。我看来，URN没被使用的原因在于：

• URN与URL是不兼容的方案。
• 搜索引擎、站内搜索、移动互联网等出现，用户不关心也记不住URL（URN也一样）。URL是Web底层的基础设施，进行改动成本很高，收益很低。
• URL的持久性没有想象中那么糟糕，合理的URL规划能满足URN所预期的功能。
• 用户习惯URL，采用URN会导致学习成本。

总而言之，多年的实践看来，URL并没有想象中那么差，URN也没有想象中那么好。

类比于现实中的人/机构的名称，URN就是Web中的资源名称。

参考：
URN讨论：RFC1737 http://www.ietf.org/rfc/rfc1737.txt
URN语法：RFC2141 http://www.ietf.org/rfc/rfc2141.txt
URN历史：《HTML权威指南》第二章 2.6 未来展望
分清 URI、URL 和 URN：https://www.ibm.com/developerworks/cn/xml/x-urlni.html#artrelatedtopics

URI

URI是统一资源标志符的缩写，它是对URL和URN的统一化抽象，URI为识别资源提供了一种简单且可扩展的手段。在其定义看来，一个URI可以作为定位符、名称或者两者的结合。通用URI语法由方案(scheme)，权威(authority)，路径(path)，查询(query)和片段(fragment)组成：

      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

可以看到从语法层面上来讲，URL与URI是存在一定的区别。关于语法区别的更多部分，可以详细阅读RFC文档。
类比于显示中的姓名、地址用来标志人，URL、URN的本意也是用来标识资源，因此统一为URI。

参考：
URI讨论：RFC1630 https://www.w3.org/Addressing/rfc1630.txt
URI语法：RFC3986 https://tools.ietf.org/html/rfc3986

使用URI还是URL？由于URN目前没有实用价值，容易混淆的概念只在于URI和URL。作为应用开发者的我们，对URI和URL的区别通常只在于命名，我的看法是：

• 根据API来命名，要什么，给什么。
• 在Web中通常需要的是具体的资源位置，因此一般使用URL

总结

本篇分析了URL,URN,URI的具体定义，他们的实际使用情况。标准在抽象、概念上很有意义，但实际开发中，往往看事实。

即使到本篇末尾，URL,URI,URN在我心仍然混乱的纠缠在一起，就像XML在我心中一样，这与其定义之初就比较抽象，相关文档也比较混乱有关。幸好实际使用并不需要太过纠结，除非涉及相关底层开发，了解到这个层次即可。

有些人会拿一些语言、库对URI,URL的理解来作为对URI,URL的理解，我认为这种方式不太正确。语言和库对URI,URL的理解可以看作其开发人员对RFC定义的相关概念的自我理解，具备一定的实践价值，但本质还是二次知识。