解決策
多くのウェブプロトコルは、サイトを利用する前にそのサイトについて何かを知る必要がある。ポリシー、設定、証明書、アプリリンク、アカウントのメタデータなどだ。取り決めがなければ、各プロトコルはルート直下のURLを独自に考案し、サイト自身のコンテンツと衝突する危険を冒すことになる。
Well-Known URIは、意図的に地味な一つの接頭辞、/.well-known/でこれを解決した。プロトコルは接尾辞を登録し、クライアントは走査したり推測したりすることなく、どこを見ればよいかを知ることができる。
その妙は抑制にある。この標準はホスティングを集中化せず、メタデータの形式も規定しない。URI空間のごく一部を予約し、IANAレジストリを追加して、発見の仕組みが予測可能なままであるようにするだけだ。
達成したこと
発見用の棚を一つ予約する
うまくいった理由
固定された接頭辞は、クライアント側の推測と余分な往復を減らす。
登録制により、プロトコル名が互いを踏みつけることを防ぐ。
サイトはURI空間の残りを自らの管理下に保つことができる。
応用できること
名前空間が地味で統治されているとき、発見の仕組みは機能する。小さな予約済みの棚一つは、百のプロトコルが勝手に玄関先のURLを奪い合うよりも優れている。
その後
このパターンは、セキュリティ、アイデンティティ、自動化のプロトコルを含む現代のウェブインフラにとって、静かな依存関係となった。ACME、WebFinger、OpenID関連の発見、security.txt形式の取り決めはすべて、オリジンレベルの事実を置くための認識された一つの場所があることの恩恵を受けている。
出典をたどる
出典
- RFC 8615: Well-Known Uniform Resource Identifiers (URIs) RFC Editor · rfc-editor.org
- Well-Known URIs registry IANA · iana.org