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_" プレフィックスを付けることは役に立ちません。なぜなら、プレフィックス自体が衝突のリスクにさらされているからです (それは "予約" されていないため)。