汚いURL

URL設計

[12] URL の決め方には、色々な流儀や主張があります。

[31] 宗教性の強い主張が多いので、深入りしないように注意しましょう。

Cool URI

[14] Cool URIs don't change は、Web の発明者である TimBL による記事とその主張です。 Webサイト著者の気まぐれにより 404 エラーが多発していた当時の状況を踏まえ、良い URL を設計する必要性と方法を説いています。

[15] 当時の意識の高い Web開発者に大きな影響を与え、 拡張子のない URL path の普及のきっかけともなりました。

[21] しかし世の中の大勢に影響を与えるまでには至りませんでした。 現実的には URL はどんどん意味のないものとなり、 ドメインは気づいたらなくなっています。 URL が変わらず機能し続けるなどというのは幻想です。

[28] とはいえ必然的な理由なく URL をころころ変えることは、 Tim の主張を繰り返すまでもなく、たしかに慎むべきでしょう。

内容折衝

Semantic Web

[10] Semantic Web の世界では、計算機上の表現でない資源 (実在する物など) を表す時、次の何れかの方法を採るのが良いとされています。

[66] URI Declaration Versus Use ( 版) http://dbooth.org/2007/uri-decl/

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] Cool URIs for the Semantic Web ( 版) http://www.w3.org/TR/cooluris/

[69] Cool URIs for the Semantic Web ( 版) http://www.w3.org/TR/2007/WD-cooluris-20071217/

[1] Cool URIs for the Semantic Web ( 版) http://www.w3.org/TR/2008/NOTE-cooluris-20081203/

[11] URI-patterns-core/URI Patterns.md at master · UKGovLD/URI-patterns-core () https://github.com/UKGovLD/URI-patterns-core/blob/master/URI%20Patterns.md

日付の入ったURL

[20] 00年代には、 URLを含めることで 「その、そのにある名前で呼ばれていた概念」 を表すことができ、 URL の永続性のために有用である、 といった考えが現れました。

[27] http: URLパス/2001/04/concept のような形とするW3C式日付入りURLW3CWebサイトで使われました。 いわゆるW3C信者を中心に、W3C 外でもごく一部で追従されました。

[26] 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名前空間名前空間URLdata:,520e273a-62ad-4528-bb1e-9652bda76d62UUID によって定め、 物議を醸しました。 固有性を重視して人間が覚えきれない日付を入れるポリシーが正当化されるなら、 固有性が高すぎて人間がまず覚えられない UUID であっても非難されるいわれはないというものです。

[25] 結果名前空間URLW3C の割当ポリシーが変更されて日付を入れる必要はなくなり >>24W3C Webサイトのそれ以外のページについても日付を入れないものが使われるように緩和されていったようです。

[29] 理論的潔癖性を追求し過ぎて実用性を蔑ろにしても破綻するという例なのでしょう。

W3CURI 割り当て方針 (割り当ての年月が入るやつ) がいけてないという話。Ian Hicksondata:,520e273a-62ad-4528-bb1e-9652bda76d62http://www.w3.org/1999/xhtml1999 のような訳の分からない数字を皮肉ったものらしいww (名無しさん 2006-07-08 04:48:18 +00:00)

[58] 確かに最近名前空間URIの年号を覚える or コピペするのがめんどくてうんざりしてるんだよ。。。 (名無しさん 2006-07-08 04:49:35 +00:00)

[36] 最速インターフェース研究会 :: Amazonのカートが仕様変更してるっぽい, 2005-10-29 17:53, http://la.ma.la/blog/diary_200510291748.htm

外部と連携するようなサービスで、フォーマットを変更する可能性がある場合には互換性を保ちつつ仕様変更できるようにURLにバージョン番号や日付なんかの識別子を含めるようにするのが良いと思う。AmazonのECSなんかはすでにそうなっているし、円滑にバージョンアップするためにはとても重要なことだと思う。

[37] Web APIURL に基づく 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 は、できるだけ揺れのない固有のものとするべきです。

[19] 例えば同じ内容のWebページURL が2種類あると、 Webブラウザー既読判定や、 ソーシャルブックマークサービスURL ごとのブックマーク数の計算で、 異なるものと判断され、利用者の利便性を損ないます。

ネイティブアプリケーション

[17] スマートフォンアプリ用の URL の共通仕様として x-callback-url があります。

名前空間 URL との関係

汚いURL

[33] 汚いURL は、 宗教的な問題だけでなく、 実際上の問題も引き起こすことがあります。

[34] セッションIDURL に含める方法は、 平成時代中期頃まで多様されていましたが、 URL の漏洩がセッションの漏洩につながり大変危険といわれていました。 最近はあまり見かけなくなりました。 URLのセキュリティー

[35] セッションID など一時的な情報が含まれ、 恒久性に乏しい URL は、 他の人に渡して Webページを紹介できないので不便です。 パーマリンクソーシャルブックマークが広まった Web 2.0 時代に問題が認識されるようになり、 SNS 時代になって通用しない技法となりました。

セキュリティーとプライバシー

[9] URLのセキュリティーの項を参照。

関連

Webサイトリニューアル失敗事例

メモ

[2] Hatena::agenda - ウェブサイト運営方針を考える(長文注意) ( 版) http://d.hatena.ne.jp/jintrick/20070822

[46] yohei-y:weblog: 良い URI の設計 http://yohei-y.blogspot.com/2005/08/uri.html

[59] hxxk.jp - 各種 weblog の URI 設計を比較してみる http://hxxk.jp/2005/11/15/1850 (名無しさん 2006-07-08 12:06:10 +00:00)

[64] Why you should be using disambiguated URLs (2007-02-10 01:07:29 +09:00 版) http://simonwillison.net/2007/Feb/4/urls/ (名無しさん 2007-02-09 16:15:26 +00:00)

Good URLs are important. The best URLs are readable, reliable and hackable.

[65] 第20回 “使いやすいURI(URL)”の設計を考える:ITpro (2007-04-28 12:10:18 +09:00 版) http://itpro.nikkeibp.co.jp/article/COLUMN/20070424/269291/ (名無しさん 2007-04-28 03:12:39 +00:00)

[49] URL Design — Warpspire ( ( 版)) http://warpspire.com/posts/url-design/