[12] [[URL]] の決め方には、色々な流儀や主張があります。 [31] [[宗教性]]の強い主張が多いので、深入りしないように注意しましょう。 * Cool URI [14] [DFN[Cool URIs don't change]] は、[[Web]] の発明者である [[TimBL]] による記事とその主張です。 [[Webサイト]]の[[著者]]の気まぐれにより [CODE[404]] エラーが多発していた当時の状況を踏まえ、良い [[URL]] を設計する必要性と方法を説いています。 [15] 当時の[[意識の高い]] [[Web開発者]]に大きな影響を与え、 [[拡張子]]のない [[URL path]] の普及のきっかけともなりました。 [21] しかし世の中の大勢に影響を与えるまでには至りませんでした。 現実的には [[URL]] はどんどん意味のないものとなり、 [[ドメイン]]は気づいたらなくなっています。 [[URL]] が変わらず機能し続けるなどというのは幻想です。 [28] とはいえ必然的な理由なく [[URL]] をころころ変えることは、 Tim の主張を繰り返すまでもなく、たしかに慎むべきでしょう。 [REFS[ - [4] [CITE[Hypertext Style: Cool URIs don't change.]] ([TIME[2014-02-25 08:09:53 +09:00]] 版) -- [38] --- [39] 移転確認 [TIME[2023-04-04T07:24:09.000Z]] --- [40] [CITE@ja[クールなURIは変わらない -- Style Guide for Online Hypertext]], [TIME[2012-09-19T16:27:47.000Z]], [TIME[2023-04-04T07:24:01.969Z]] - [56] [CITE[GoodURIs - ESW Wiki]] ]REFS] ** 内容折衝 @@ [REFS[ - [67] [CITE@en[h3h.net - Designing URLs for Multilingual Web Sites]] ([CODE[2007-10-07 21:44:44 +09:00]] 版) ]REFS] ** Semantic Web [10] [[Semantic Web]] の世界では、[[計算機]]上の表現でない[[資源]] (実在する物など) を表す時、次の何れかの方法を採るのが良いとされています。 [FIG(list)[ - [[ハッシュURL]]を使う ([[RDF]] でその[[資源]]について説明する) - [[素片識別子]]のない [CODE(URI)@en[http:]] [[URL]] を使い、 [[HTTPサーバー]]は [CODE(HTTP)[303]] [[応答]]を返してその[[資源]]について説明した [[RDF]] に[[リダイレクト]]する ]FIG] [66] [CITE[URI Declaration Versus Use]] ([TIME[2007-08-02 13:08:18 +09:00]] 版) >A URI declaration permits assertions about a URI's associated resource to be classified into two groups: core assertions, whch are provided by the URI declaration, and ancillary assertions, which are all others. This distinction enables different parties to share a common understanding of the associated resource (by accepting the core assertions) while making different choices about which ancillary assertions to accept. Resource identity is established by a two-step mapping from a URI to a set of core assertions, and hence through an interpretation to the resource that is denoted by that URI. This paper defines these concepts and proposes some related best practices and a Web architectural rule specifying how URIs for non-information resources can be conveniently declared using existing hash or hashless (303-redirect) URI mechanisms. [3] [CITE[Cool URIs for the Semantic Web]] ([TIME[2008-12-03 00:30:18 +09:00]] 版) [69] [CITE[Cool URIs for the Semantic Web]] ([TIME[2007-12-14 19:15:28 +09:00]] 版) [1] [CITE[Cool URIs for the Semantic Web]] ([TIME[2008-12-03 00:30:18 +09:00]] 版) [11] [CITE@en[URI-patterns-core/URI Patterns.md at master · UKGovLD/URI-patterns-core]] ([TIME[2016-06-30 12:46:21 +09:00]]) ** 日付の入ったURL [20] [[00年代]]には、 [[URL]] に[[年]]や[[月]]を含めることで 「その[[年]]、その[[月]]にある名前で呼ばれていた概念」 を表すことができ、 [[URL]] の永続性のために有用である、 といった考えが現れました。 [27] [CODE(URI)@en[http:]] [[URL]] の[[パス][URL path]]を [CODE[/2001/04/concept]] のような形とする[DFN[W3C式日付入りURL]] が [[W3C]] の [[Webサイト]]で使われました。 いわゆる[[W3C信者]]を中心に、[[W3C]] 外でもごく一部で追従されました。 [26] [CODE(URI)@en[tag:]] [[URL]] も[[ドメイン名]]の所有者変更などまで考慮して、 [[日付]]を [[URL]] 構文に組み込んでいます。 [22] 元から[[ブログ]]や[[ニュース]]のように[[日付]]を [[URL]] に含めることは一部の用途で行われており、それ自体は不自然なことではありませんでした。 [23] しかし[[名前空間URL]]に[[日付]]を含めて永続性を担保することを目指した結果、 [[著者]]が[[名前空間URL]]の[[日付]]を一々覚えないといけなくなったり (例えば [[HTML名前空間]]は 1999、[[SVG名前空間]]は 2000、 [[MathML名前空間]]は 1998)、 「下部組織の設立日が入った階層下にある記事出版日の入った記事の URL」 のような複数の日付が入った複雑な URL が出現したりして、 実用性を無視した奇怪な [[URL]] 割当ポリシーには疑問が持たれるようになりました。 ;; [30] [[名前空間URL]]などはきっとソフトウェアが自動生成するから人間が書くことはそれほど多くないとでも思っていたのでしょうが、 現実的にはいろいろな人が書く羽目になっていました (いわゆる [[tools save us]] 神話)。意味もわからず誤記したまま[[コピペ]]しているような例も少なくありませんでした。 [32] [[HTML5]] の父、 [[Ian Hickson]] は、 意味不明な日付 [[URL]] を皮肉って、 自身の編集する[[仕様書]]内で [[XML名前空間]]の[[名前空間URL]]を [CODE[data:,520e273a-62ad-4528-bb1e-9652bda76d62]] と [[UUID]] によって定め、 物議を醸しました。 固有性を重視して[[人間]]が覚えきれない[[日付]]を入れるポリシーが正当化されるなら、 固有性が高すぎて[[人間]]がまず覚えられない [[UUID]] であっても非難されるいわれはないというものです。 [25] 結果[TIME[2006年9月][2006-09]]に[[名前空間URL]] の [[W3C]] の割当ポリシーが変更されて日付を入れる必要はなくなり [SRC[>>24]]、 [[W3C]] [[Webサイト]]のそれ以外のページについても日付を入れないものが使われるように緩和されていったようです。 [29] 理論的潔癖性を追求し過ぎて実用性を蔑ろにしても破綻するという例なのでしょう。 [REFS[ - [57] [CITE[www-tag@w3.org from June 2006: by thread]] [[W3C]] の [[URI]] 割り当て方針 (割り当ての年月が入るやつ) がいけてないという話。[[Ian Hickson]] の は の [Q[1999]] のような訳の分からない数字を皮肉ったものらしいww ([[名無しさん]] [WEAK[2006-07-08 04:48:18 +00:00]]) [58] 確かに最近[[名前空間URI]]の年号を覚える or コピペするのがめんどくてうんざりしてるんだよ。。。 ([[名無しさん]] [WEAK[2006-07-08 04:49:35 +00:00]]) - [5] [CITE[URIs for W3C Namespaces]] ([TIME[2007-07-20 05:24:56 +09:00]] 版) - [24] [CITE@en[Short namespace URIs for W3C TRs available]] ([[Ian B. Jacobs]] 著, [TIME[2006-09-07 11:52:42 +09:00]] 版) - [6] [CITE@en[W3C URI Persistence Policy]] ([TIME[2015-08-29 01:19:06 +09:00]] 版) ]REFS] [36] [CITE[最速インターフェース研究会 :: Amazonのカートが仕様変更してるっぽい]], 2005-10-29 17:53, [TIME[2022-06-13T09:13:33.000Z]] > 外部と連携するようなサービスで、フォーマットを変更する可能性がある場合には互換性を保ちつつ仕様変更できるようにURLにバージョン番号や日付なんかの識別子を含めるようにするのが良いと思う。AmazonのECSなんかはすでにそうなっているし、円滑にバージョンアップするためにはとても重要なことだと思う。 [37] [[Web API]] の [[URL]] に基づく [[versioning]] を提唱した早い例かな? * REST [8] [[Cool URI]] が良い、という話は [[REST]] 推進者からも出てきます。 しかし [[REST]] な設計と言われるものには [[Cool URI]] とは矛盾しそうなものもあります。 [[REST]] といっても色々あるので、一枚岩では無さそうです。 ;; 詳しくは [[REST]] 参照。 * Web アプリケーション [13] [[悪いWeb API設計]]も参照。 [16] [[OpenURL]] など、特定の [[API]] を規定して色々な[[サーバー]]で実装されることを期待しているものもあります。 [18] [[Webページ]]の [[URL]] は、 [[Webブラウザー]]の[[ブックマーク]]や[[ソーシャルブックマークサービス]]、 [[SNS]] の[[共有]]機能など、当該 [[Webサイト]]外でも色々な場面で使われます。 [[Webページ]]の [[URL]] は、できるだけ揺れのない固有のものとするべきです。 [EG[ [19] 例えば同じ内容の[[Webページ]]の [[URL]] が2種類あると、 [[Webブラウザー]]の[[既読判定]]や、 [[ソーシャルブックマークサービス]]の [[URL]] ごとの[[ブックマーク]]数の計算で、 異なるものと判断され、[[利用者]]の利便性を損ないます。 ]EG] * ネイティブアプリケーション [17] [[スマートフォンアプリ]]用の [[URL]] の共通仕様として [[x-callback-url]] があります。 * 名前空間 URL との関係 ;; [7] [[名前空間の管理]]も参照。 * 汚いURL [33] [DFN[汚いURL]] は、 [[宗教的]]な問題だけでなく、 実際上の問題も引き起こすことがあります。 [34] [[セッションID]]を [[URL]] に含める方法は、 [[平成時代]]中期頃まで多様されていましたが、 [[URL]] の漏洩が[[セッション]]の漏洩につながり大変危険といわれていました。 最近はあまり見かけなくなりました。 [SEE[ [[URLのセキュリティー]] ]] [35] [[セッションID]] など一時的な情報が含まれ、 恒久性に乏しい [[URL]] は、 他の人に渡して [[Webページ]]を紹介できないので不便です。 [[パーマリンク]]や[[ソーシャルブックマーク]]が広まった [[Web 2.0]] 時代に問題が認識されるようになり、 [[SNS]] 時代になって通用しない技法となりました。 * セキュリティーとプライバシー [9] [[URLのセキュリティー]]の項を参照。 * 異なる自然言語の版をどう区別するか @@ * 異なるデータ形式の版をどう区別するか @@ [43] 例えば[[画像形式]]の違い、 [[Microsoft Word]] 版と [[PDF]] 版の違い * 利用者名 (アカウント名) を URL にどう入れるか [41] [[URL path]] に入れる場合について: [SEE[ [[HTTP(S) URL]] ]] [42] [[ドメイン]]に入れる場合について: @@ * UGC の名前をどう決めるか @@ [44] 定石は[[固有ID]]を機械的に採番する方式です。 ただし使いにくくなるというのが悩みどころです。 -*-*- @@ [45] 題名から取るという方式 [50] [[パーセント符号化]]で扱いにくくなるのが困りどころです。 @@ [48] ほとんどすべての[[ウィキ]]は[[ウィキ名]]をそのまま使います。 - [47] [CITE@ja[Speaker Deck で変な URL 付けられるのを抑制する - 肉とビールとパンケーキ by @sotarok]], [TIME[2025-03-03T10:42:40.000Z]] -*-*- [51] [[CMS]] などには[[著者]]が自分で指定する機能を備えているものもあります。 [54] 実装は、他との衝突回避や [[URL]] として不適切な[[文字]]の処置などの配慮をしなければなりません。 - [52] [[HTTPヘッダー]]の [CODE[Slug:]] - [53] [[WordPress]] の[[スラッグ]] ([[slug]]) * 関連 [SEE[ [[Webサイトリニューアル失敗事例]] ]] * メモ [2] [CITE[Hatena::agenda - ウェブサイト運営方針を考える(長文注意)]] ([TIME[2007-08-31 17:39:11 +09:00]] 版) [46] [CITE[yohei-y:weblog: 良い URI の設計]] [59] [CITE[hxxk.jp - 各種 weblog の URI 設計を比較してみる]] ([[名無しさん]] [WEAK[2006-07-08 12:06:10 +00:00]]) [64] [CITE[Why you should be using disambiguated URLs]] ([CODE[2007-02-10 01:07:29 +09:00]] 版) ([[名無しさん]] [WEAK[2007-02-09 16:15:26 +00:00]]) >Good URLs are important. The best URLs are readable, reliable and hackable. [65] [CITE@ja[第20回 “使いやすいURI(URL)”の設計を考える:ITpro]] ([CODE[2007-04-28 12:10:18 +09:00]] 版) ([[名無しさん]] [WEAK[2007-04-28 03:12:39 +00:00]]) [49] [CITE[URL Design — Warpspire]] ( ([TIME[2011-01-05 03:41:37 +09:00]] 版))