2. Best Current Practices for Standardizing Structured URIs (结构化 URI 标准化的最佳当前实践)

本节通过建议规范应如何在 URI 中定义结构和语义来更新 [RFC3986]。最佳实践因所涉及的 URI 组件而异，如下所述。

2.1. URI Schemes (URI 方案)

应用程序和扩展可以要求使用一个或多个特定的 URI 方案；例如，要求应用程序支持 "http" 和 "https" URI 是完全可以接受的。但是，应用程序不应 (ought not) 排除将来使用其他 URI 方案，除非它们显然只能与指定的方案一起使用。

为 URI 方案整体定义子结构 (例如，URI 方案名称的前缀或后缀) 的规范必须 (MUST) 通过修改 [BCP35] 来实现 (一种特殊情况)。

方案定义定义了 URI 中授权机构组件的存在、格式和语义；所有其他规范禁止 (MUST NOT) 约束或定义 URI 授权机构的结构或语义，除非它们更新方案注册本身或其所依赖的结构 (例如，[RFC1034] 第 3.5 节中定义的 DNS 名称语法)。

例如，扩展或应用程序不能说 "https://foo_app.example.com" 中的 "foo" 前缀是有意义的或在 URI 中触发特殊处理，除非它们更新 "http" URI 方案或 DNS 主机名语法。

应用程序可以在适用时指定或约束它们使用的端口。例如，BarApp 可以在端口 nnnn 上运行 (前提是它已正确注册)。

方案定义定义了 URI 中路径组件的存在、格式和语义，尽管这些通常委托给给定部署中的应用程序。

为避免冲突、僵化和错误的客户端假设，规范禁止 (MUST NOT) 为其 URI 路径定义固定前缀 -- 例如，"/myapp" -- 除非方案定义允许。

此要求的一个例外是 [RFC8615] 指定的已注册 "众所周知的 (well-known)" URI。有关该机制的适用性描述，请参阅该文档。

请注意，这不适用于在服务器控制的资源 "下" 定义 URI 路径结构的应用程序。因为前缀在部署应用程序的一方的控制之下，所以避免了冲突和僵化，并且降低了错误客户端假设的风险。

例如，应用程序可以将 "app_root" 定义为部署控制的 URI 前缀。然后可以假定应用程序定义的资源存在于 "{app_root}/foo" 和 "{app_root}/bar"。

扩展禁止 (MUST NOT) 在单个 URI 组件内定义结构 (例如，前缀或后缀)，同样是为了避免冲突和错误的客户端假设。

URI 的查询组件的存在、格式和语义取决于许多因素，并可能受到方案定义的约束。通常，它们由资源本身的实现确定。

应用程序可以为其控制下的资源指定查询的语法。但是，这样做可能会给不支持特定查询形式的部署带来操作困难。例如，站点可能希望使用不支持查询参数的 "静态" 文件来支持应用程序。

扩展禁止 (MUST NOT) 约束查询的格式或语义，以避免冲突和错误的客户端假设。例如，指示所有名为 "sig" 的查询参数指示加密签名的扩展将与站点上可能预先存在的查询参数发生冲突，并导致客户端假设任何匹配的查询参数都是签名。

根据 [HTML5] 的 "表单提交 (Form submission)" 部分，HTML 约束表单提交中使用的查询字符串的语法。鼓励新的表单语言允许创建更广泛的 URI (例如，通过允许表单创建新的路径组件等)。

[RFC3986] 的第 3.5 节将片段标识符的语法和语义指定为取决于可能检索的资源的媒体类型。因此，其他规范禁止 (MUST NOT) 在片段标识符内定义结构，除非它们明确定义一个供媒体类型在其定义中重用 (例如，JSON Pointer [RFC6901] 所做的那样)。

在不受其控制的媒体类型中定义通用片段标识符的应用程序将导致与这些媒体类型的处理程序的互操作性问题 (因为不期望新的非标准语法)。