3. Alternatives to Specifying Structure in URIs (在 URI 中指定结构的替代方案)

鉴于第 1 节中描述的问题，希望使用 URI 的应用程序和扩展最成功的策略是按照它们的设计目的使用它们：作为作为协议的一部分交换的链接，而不是静态指定的语法。几个现有规范可以在这方面提供帮助。

[RFC8288] 指定了 Web 链接的关系类型 (relation types)。通过为 Web 上的链接提供一个框架，其中每个链接都有关系类型、上下文和目标，它允许应用程序定义链接的语义和连接性。

[RFC6570] 为 URI 模板 (URI Templates) 提供了标准语法，可用于将特定于应用程序的变量动态插入 URI，以启用此类应用程序，同时避免侵犯 URI 所有者对它们的控制。

[RFC8615] 允许在选择加入该机制的 URI 方案上为标准使用 "保留" 特定路径 (默认情况下为 "http" 和 "https")。但是请注意，这不是需要结构化 URI 的应用程序的通用 "逃生阀"；有关更多信息，请参阅该规范。

为避免冲突而指定更复杂的结构不是可接受的解决方案，也无法解决第 1 节中描述的问题。例如，为查询参数加上 "myapp_" 前缀没有帮助，因为前缀本身存在冲突风险 (因为它不是 "保留的")。