クールなURL

Edit New

URL設計

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

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

目次

  1. Cool URI
    1. 内容折衝
    2. Semantic Web
    3. 日付の入ったURL
  2. REST
  3. Web アプリケーション
  4. ネイティブアプリケーション
  5. 名前空間 URL との関係
  6. 汚いURL
  7. セキュリティーとプライバシー
  8. 異なる自然言語の版をどう区別するか
  9. 異なるデータ形式の版をどう区別するか
  10. 利用者名 (アカウント名) を URL にどう入れるか
  11. UGC の名前をどう決めるか
  12. 関連
  13. メモ

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

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

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

W3C の URI 割り当て方針 (割り当ての年月が入るやつ) がいけてないという話。Ian Hickson の data:,520e273a-62ad-4528-bb1e-9652bda76d62 は http://www.w3.org/1999/xhtml の 1999 のような訳の分からない数字を皮肉ったものらしい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 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 は、できるだけ揺れのない固有のものとするべきです。

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

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

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

名前空間 URL との関係#✎

[7] 名前空間の管理も参照。

汚いURL#✎

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

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

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

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

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

異なる自然言語の版をどう区別するか#✎

異なるデータ形式の版をどう区別するか#✎

[43] 例えば画像形式の違い、 Microsoft Word 版と PDF 版の違い

利用者名 (アカウント名) を URL にどう入れるか#✎

[41] URL path に入れる場合について: HTTP(S) URL

[42] ドメインに入れる場合について:

UGC の名前をどう決めるか#✎

[44] 定石は固有IDを機械的に採番する方式です。 ただし使いにくくなるというのが悩みどころです。
[45] 題名から取るという方式

[50] パーセント符号化で扱いにくくなるのが困りどころです。

[48] ほとんどすべてのウィキはウィキ名をそのまま使います。

[51] CMS などには著者が自分で指定する機能を備えているものもあります。

[54] 実装は、他との衝突回避や 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/

Updated:

Google search: クールなURL

三