URI 与资源定义

URI syntax: <scheme>:<scheme-specific-part>

generic URI syntax: <scheme>://<authority><path>?<query>

此前对 URI、URL 的定义一知半解，网上充斥着大量文档试图描述 URI、URL、URN 的区别。其中一种经典的观点是：URI 是 URN、URL 的超集。其中 URN 被用来描述资源的名称(身份ID)，而 URL 被用来描述查找该资源的方法。这个表述确实没有问题，但对于理解 URx 无法提供切实的帮助。最近阅读了 RFC 3305 、 RFC 3986 、 RFC 7595 等资料，本文将聊聊个人对 URI 的见解，以及借此回顾此前参与的公司权限系统的设计。

URI 的定义

早期充斥着大量的 RFC 在分别尝试规范 URI 、 URL 、 URN ，并且对 URx 做差异化定位。但这事实上造成了使用上的混乱，甚至一定程度上造成 “VIM or Emacs” 式的技术人员经典辩论。

URI (Uniform Resource Identifier):

• Uniform: 指统一的，保证向前向后兼容，一套标准适配所有场景。在标准中体现为 URI 句法中的 <scheme>

• Resource: 资源，所有的一切，抽象的、具体的，人、公司、电子文件、服务等均可被标识为资源

• Identifier: 数字化所必须的对资源的标识，就像如何在中国唯一定位一个公民，用身份证号就可以了。

总的来说，URI 就是为标记资源提供一套统一标准，为不同类资源的区分提供一套可供扩展的框架。 <scheme>:<scheme-specific-part> 句法由 URI 定义， <scheme> 注册列表由 IANA 负责维护，而 <scheme-specific-part> 部分，就交由 scheme 注册方负责定义了。

至于 URL ，被划入了 URI 的子集，被通用的 URI 所包容。从个人的观点看，是一个被互联网标准淘汰了的产物，只是因为 WWW 使用太过于广泛，这个历史名词一直停留在日常用语中。但翻阅标准文档，近些年的文档已经选择性地规避 URL 的使用。而更多地被 URI 所囊括。

另外还有一个 IRI (Internationalized Resource Identifiers) ，提出要替代 URI ，但目前更多的是作为 URI 的扩展而存在。URI 只支持 ASCII 字符集，而 IRI 使用 Unicode 来适应国际化的需求。

权限与资源标识

借着对 URI 的重新认识，又想起了去年参与做的权限系统。当时在设计中就提出了所有的资源都可以作为权限，唯一的需求就是对资源进行标识。不过如何对资源的标识就陷入了一个极其痛苦决策。就需求来说，面对的标准和非标的资源有：

• 大前端的组件
• 服务端的方法块
• 数据库表的字段
• HTTP(s) scheme 的 URI 等。

如何将资源纳入统一的标识框架？从现在的观点来看，URI 早就为这种问题提供了可供扩展的解决方案。但在知识面狭隘的前提下，自定义协议往往是技术人员的第一选择，恰恰是标准化的 HTTP(s) scheme 直接被权限系统放弃，我们对非标资源进行了自定义的命名( <type>:<unique name> )

回顾这一年多的实践，非标的资源被诟病最多的就是代码侵入，虽然切面编程缓解了问题，但无法根除。而被直接放弃的 HTTP(s) scheme ，恰恰拥有更广泛地群众基础。虽然通过扩展自定义协议可以重新引入对 HTTP(s) scheme 的支持，但终归来说是协议上的重大缺陷。

微不足道的总结

自定义协议可以解决眼前的问题，但立场决定了设计的高度。URI 试图为标识资源提供统一标准，提供了高度可扩展的标准；而我此前的资源权限命名，局限于将需求中的资源纳入，最终也只是将部分需求做了统一化。

历史为整个互联网储备了大量优秀的技术和解决方案。公开标准可能无法次次都完美地符合需求，但至少先了解了解标准制定者所面临的问题和提供的解决方案，可以扩展解决问题的思路，查漏补缺。