Internet Engineering Task Force (IETF) J. Gregorio Request for Comments: 6570 Google Category: Standards Track R. Fielding ISSN: 2070-1721 Adobe M. Hadley MITRE M. Nottingham Rackspace D. Orchard Salesforce.com March 2012 URI Template Abstract A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification def
一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する
URI.js is a javascript library for working with URLs. It offers a "jQuery-style" API (Fluent Interface, Method Chaining) to read and write all regular components and a number of convenience methods like .directory() and .authority(). URI.js offers simple, yet powerful ways of working with query string, has a number of URI-normalization functions and converts relative/absolute paths. While URI.js p
PHP の $_SERVER['REQUEST_URI'] と parse_url() の予想外な動作について。 - こせきの技術日記 の続き。 PHPのparse_url()は、 "/abc?a=x&time=09:00&x=y" はパースできるのに、 "/abc?a=x&time=09:00" だと失敗する。 相対URIで「動作しない」仕様だかららしいのだが、それはともかく、コロンのパーセントエンコードが必須なのか気になったので調べた。 URIの仕様 RFC 3986 まず、基礎となる URI の仕様 RFC 3986 がある。 RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax Uniform Resource Identifier (URI): 一般的構文 日本語訳 RFC 1738 - A Gopher URL
今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか？ 前提として、設計するWebサイトには、conversation（会話）というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。（IDは数字とは限らない識別子） /conversa
What are the criteria for a good REST-ful URI? I assert: Short (as possible). This makes them easy to write down or spell or remember. Hackable 'up theWhat are the criteria for a good REST-ful URI? I assert: Short (as possible). This makes them easy to write down or spell or remember. Hackable ‘up the tree’. The user should be able to remove the leaf path and get an expected page back. e.g. http:/
uri = URI.parse("mysql://u-kondo:XXXXX@localhost:3306/hogege") uri.class #=> URI::MySQL uri.host #=> localhost require 'uri' require 'active_record' class URI::MySQL < URI::Generic def default_port 3306 end def database path[1..-1] rescue nil end def connection_hash { :adapter => scheme, :host => host, :username => user, :password => password, :database => database, :encoding => 'utf8', :port => p
URL設計の前段階として、とても大切なのがリソース設計です。そのWebアプリ・Webサービスで何を提供するのかが決まる部分だからです。しかし、なかなかリソースという概念が定着していないようなので、Railsで採用されているパターン*1を例に挙げて紹介してみたいと思います。 今までのシリーズ記事と重なるところもありますが、まとめということで…。 リソースとは 簡単に言うと、「URLで示されるもの」です。URLというのが“Uniform Resource Locator”の略ですからね。 http://d.hatena.ne.jp/tkawa/20110819/p1 http://d.hatena.ne.jp/tkawa/20110819 最初のものは、前回書いたブログ記事『RailsでのURL設計を考えてみる(4) スラッシュと「持っている」関係』というリソースです。 その次は、『tkawa
諸方面からお叱りの言葉しかいただけない#!なURLは様々な問題をはらんでいますが、来るべき未来(もうすぐですよ！)におけるメンテナンス性という問題についてAdactioで取り上げられていました。#!の表面的な凶悪さに思考停止していて、こういった本質的な問題についてはまったく考えていなかった気がします。 その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。 この#!なURLのメンテナンス性の悪さという問題は、URLの#以降はクライアント側の扱いなので、クラ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started |
関心事オブジェクトの「現在の状態」を利用者に提供するパターンのひとつが、REST スタイルの GET 方式。 GET /リソースの識別名(URI) をサーバーにリクエストすると、「現在の状態 ( current state )」の表現 ( Representation ) がかえってくる、というやつですね。 ドメインモデリングのパターンとして、私は、「リソース」を「関心事オブジェクト」、「ＵＲＩ」を「識別キー」という言葉にしている。 実際に、HTTP を使うかどうかは別として、 ◎ リソース（＝関心事オブジェクト）の ◎ URI (＝識別キー) を指定して ◎ 現在の状態(current state)を入手する というのは、エンタープライズアプリケーションの基本価値のひとつですね。 「関心のあることを知る」という業務の基本ニーズ。 このニーズに応えるための GET 方式のモデリング・設計は
先日の記事に、ブックマークでコメントをいただいたので、少し。 # tkawa 「http://example.jp/users」もリソースになるね、とか考え始めたら「example.jp/users/」もリソースになるねというツッコミも可能。"/"にとらわれる必要もないし、提供しないなら403でいいと思う。パンくずリストはまた別の問題 まず、"/"付きのURLは想定外でした。コレクションのリソースを返す場合でも"/"なしのURLを使いそうだし、"/"付きのURLがリクエストされたら、403?404?にするのかな。それとも"/"なしにリダイレクトするか？ 『Webを支える技術』第2部に書いてあったらなあ、と責任逃れ。 id:tkawaさんのご指摘のとおり、想定されるすべてのリソースを提供すべきというのは無茶かもしれません。一方で、URLが（擬似的な？）階層構造になっているとすると、その途中も
先日の日記でひねり出した「識別子結合方式」のURIは、現実のWebサービスでは見かけないので、「またいつものように僕だけが突飛なことを考えているんだろう」とひとりごちていたら、ふと、Wikipediaで使われていることに気づきました。 Wikipediaの名前空間 Wikipediaには、MediaWiki由来の名前空間概念があります。詳しくは下記リソースをご参照ください。 http://ja.wikipedia.org/wiki/Help:名前空間 お察しの通り、このURI自体が、名前空間の使用例になっています。名前空間を示すプレフィックス「Help」と定義語「名前空間」を区切り文字「:」で結合しているわけです。 なぜ名前空間が必要かといえば： http://ja.wikipedia.org/wiki/名前空間 で提供されるリソースと区別する必要があるからにほかなりません。 この考え方は
先日書いた「こんなURI 設計、どう？」の続きです。 例：商品ブックマークサービス URI設計の例として、商品ブックマークサービスを対象に考えてみます。提供するおもなリソースは、以下の5つです。 リソース名 パンくずリストのイメージ トップレベルリソース トップ ユーザ登録画面リソース トップ＞ユーザ登録 ユーザ別ブックマークリソース トップ＞iwamotのブックマーク ブックマークリソース トップ＞iwamotのブックマーク＞Webを支える技術 商品リソース トップ＞Webを支える技術 うち商品リソースについては、はてなブックマークのエントリページ（例：http://b.hatena.ne.jp/entry/twitter.com/）みたいなものとお考えください。商品ブックマークサービスでは、entry以下のURI断片の代わりに、Amazonの商品コード（ASIN）を用いることにします。
使いやすいURI（URL）とは，覚えやすく，読んですぐにページの内容がわかるURIのことです。前回の記事では，使いやすいURIを設計するための11個のルールのうち，5番目までを説明しました。今回は残りのルールについて説明します。 改造しやすいURIにする 「改造しやすいURI」というのは，英語では「hackable」と表現されています。これは，URIを削ったり，文字を一部変えたりすることで，目的のページにアクセスできるURIにしよう，という意味です。 例えば，以下のようなブログ・サービスのURIがあったとします。 http://blog.example.com/entry/2007/04/20 これはおそらく，2007年4月20日に投稿された記事の一覧ページではないかと想像できます。それでは，2007年3月3日に投稿された記事のページにアクセスしたいとしたら，どうしたらいいでしょうか。 お
今回は「URIの使いやすさ」について考えてみたいと思います。URIの使いやすさ，というのは，ウェブサイトやウェブ・アプリケーションにおいて，どういうURIでそれぞれのページにアクセスできるようにすると，利用者は使いやすいのか，ということです。つまりは，どのようにURIを設計するのがいいんだろう，ということです。URIの設計については，これまでもいろいろなところで議論がなされていますので，それらの議論や動向などを見ながら，考えていきたいと思います。 URIを話題として取り上げようと思ったのは，4月の4，5日に行われたYAPC ASIA 2007（YAPCはYet Another Perl Conferenceの略）で，Six Apartの創業者でMovable Typeの生みの親であるBen Trott氏がSix Apartのサービス「Vox」について発表を行ったとき，「Voxの出力するRS
2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く