URI 設計の例 ： 郵便番号と住所 | システム設計日記
「住所」を例に、関心事オブジェクトの 識別キー（URI) 設計の例。 日本郵便の郵便番号検索を参考にしてみた。 http://www.post.japanpost.jp/zipcode/ URI のおさらい URI は、ネットワーク上の資源（リソース）を特定するための、 Scheme : "http:" Server : "//www.post.japanpost.jp" Path : "/zipcode/" Query : ?name=value Fragment : #ページ内のブロックのid という構造の識別方式。 「知りたいと思っていること」を、この形式で、どうやって、表現するのが使いやすいサービスだろう？ 日本郵便の実際のサイトの Path と Qeury を参考にしながら、リソース指向アーキテクチャ(ROA)っぽい、URI 設計にチャレンジしてみる。 path 名は、日本語のほ
たかが URI の設計、されど URI の設計 | システム設計日記
関心事オブジェクトの「現在の状態」を利用者に提供するパターンのひとつが、REST スタイルの GET 方式。 GET /リソースの識別名(URI) をサーバーにリクエストすると、「現在の状態 ( current state )」の表現 ( Representation ) がかえってくる、というやつですね。 ドメインモデリングのパターンとして、私は、「リソース」を「関心事オブジェクト」、「ＵＲＩ」を「識別キー」という言葉にしている。 実際に、HTTP を使うかどうかは別として、 ◎ リソース（＝関心事オブジェクト）の ◎ URI (＝識別キー) を指定して ◎ 現在の状態(current state)を入手する というのは、エンタープライズアプリケーションの基本価値のひとつですね。 「関心のあることを知る」という業務の基本ニーズ。 このニーズに応えるための GET 方式のモデリング・設計は
ハックしやすいURIについて少し - winplusの日記
先日の記事に、ブックマークでコメントをいただいたので、少し。 # tkawa 「http://example.jp/users」もリソースになるね、とか考え始めたら「example.jp/users/」もリソースになるねというツッコミも可能。"/"にとらわれる必要もないし、提供しないなら403でいいと思う。パンくずリストはまた別の問題 まず、"/"付きのURLは想定外でした。コレクションのリソースを返す場合でも"/"なしのURLを使いそうだし、"/"付きのURLがリクエストされたら、403?404?にするのかな。それとも"/"なしにリダイレクトするか？ 『Webを支える技術』第2部に書いてあったらなあ、と責任逃れ。 id:tkawaさんのご指摘のとおり、想定されるすべてのリソースを提供すべきというのは無茶かもしれません。一方で、URLが（擬似的な？）階層構造になっているとすると、その途中も
『Webを支える技術』第2部 - winplusの日記
『Webを支える技術 -HTTP、URI、HTML、そしてREST』 第2部で、とくに面白かったところ。 URIはWebサービスやWeb APIの設計において最も重視すべきパーツであると言えるでしょう。 ■クールなURI 変わらない シンプル 覚えやすい もちろんURIを変わりにくくする指針もまとめられている。 この「シンプル」「覚えやすい」というのは、「リソースのセマンティクスがパスの見た目で自明ならフラットなほうが好み。」というid:yoheiさんのコメントと、とうぜん一致している。で、たぶん難しいのは「自明」の基準。id:IwamotoTakashiさんは第15章に掲載されているURIの例を「自明」でないと感じておられるようだし、それは理解できる。少し冗長であっても記述的なURIの方にひかれる。 ■URIの不透明性 WebサービスやWeb APIをハックして情報を勝手に取り出したいと
{アカウント毎,ログイン後}の URL 設計 -- LoveVector
Abstract 各ユーザアカウントごとにリソースを持ったりする類のウェブアプリケーションの URL 規則に悩む。 (Article) 以下のような仕様のウェブアプリケーションの URL 付けに悩む。 各ユーザがアカウントを持ち，ログインできる 各ユーザが何らかのデータを，ログインしている他ユーザや，あるいは非ログインユーザに公開できる ログインしたときにだけアクセス可能な画面がある 以下は，この 2 と 3 の URL をどうしましょか，というお悩み相談。 アカウントごとのURL 2 を実現するために，よく http://example.jp/home/klm/ （klm はユーザ名）みたいな URL が用いられる。この URL をどうしようか，というのが，ひとつめの悩みどころ。 a. 直下にユーザ名: del.icio.us や，はてなのそれぞれのサービスなどがこれ。間に何も挟まず，h
第21回 “使いやすいURI（URL）”の設計を考える（続編）
使いやすい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日に投稿された記事のページにアクセスしたいとしたら，どうしたらいいでしょうか。 お
第20回 “使いやすいURI（URL）”の設計を考える
今回は「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
新規リソース作成用のリソース - winplusの日記
id:IwamotoTakashiさんの問題提起「こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）」を読んで、少しだけ考えたこと。 コメントさせていただいたとおり、Rails流の「{データの種類}/{データのキー}」というURLには、そんなに抵抗はない。 しかし、Rails流でも、新規リソース作成用のリソース（たとえば登録用のフォームだとか）を「{モデル名}/new」からGETするというやりかたは、すこし微妙な感じがする。 GET http://rest.jp/users/123 => ID=123のユーザのリソース GET http://rest.jp/users/new => 新規ユーザ作成用のリソース どちらもユーザのリソースであるという意味では「自然な」URLだろう。ところが後者は、「新規ユーザ作成用のリソース」と「newというIDのユーザ」と両方にとることができる。も
//から始まるURL - by edvakf in hatena
このブログでも前に一回出てきたことがあるんだけど、// から始まる URL のことが紹介されていた。(問題・このブログのどの記事で出てきたでしょうか?) Using Protocol Relative URLs to Switch between HTTP and HTTPS - HttpWatch Blog <img src="//example.com/img/foo.jpg" />とか書いてあると、そのページのプロトコル (http: か https:) をブラウザが勝手に補完してくれるので HTTP と HTTPS を使い分けるのに便利だよっていう話。 ただし、IE7と8では // から始まる URL で指定されたスタイルシートは何故か2回リクエストが出てしまうので気をつけましょう。…らしい。(受け売りです) High Performance Web Sites :: 5a Mis
RESTfulなWebサイトと拡張子を含むURLについて - 檜山正幸のキマイラ飼育記 (はてなBlog)
2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
HTTPメソッド、URL、そして標準化された動詞 - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記]「訂正補足：HTTPメソッド、URL、そして標準化された動詞」、「そろそろ決着、HTTPメソッド、URL、そして標準化された動詞」を書きましたので、あわせてお読みください。[/追記] 「HTTPメソッドの正統的使い方と現実的対処法」において、HTTPメソッドの本来の意味と、その本来の意味を損なわずにブラウザからリクエストする方法を述べました。最近また、Catyとの関係で、HTTPメソッドとURLをどう使うのが望ましいのか？ という問題を考えました。 HTTPメソッドには、GET, PUT, DELETE, HEAD, POST がありますが、ブラウザから発行できるメソッドはGETとPOSTだけです。「HTTPメソッドの正統的使い方と現実的対処法」において、GET/POSTを使って他のメソッド（PUT, DELETE, HEAD）を表現するために、_methodというクエリパラメータ
[REST][読書メモ] 変化するURI, 非同期処理
間違って消してしまったので再投稿・・・ == 『RESTful Webサービス』を読んでいて、ちょうど今突き当たっている問題のヒントを発見したのでふたたびメモ。注意して読んだつもりだけど、初心者なので誤解があるかも。 ひとつは、PUT操作でリソース状態を変更すると、URIが変わるケース。 たとえばユーザーアカウント名を変えられるシステムで、ユーザーリソースURIにアカウント名が含まれている場合。アカウント名を変更するとURIが変わってしまう。 これに似た要求があったとき、なんだか私はとても違和感をおぼえた。まぁ、一意でさえあれば変化しようと問題ないのかな・・・と若干もやもやしつつ実装したんだけど。 このあたりの議論が "8.13 永続的なURIと読み取り可能なURI"にあった。 URIの構築の仕方には２つのポリシーがある。①「永続的なURI」の立場URIは、変化する現実とは関わりをもたない
A proposal for making AJAX crawlable
accessibility 10 advanced 195 AMP 13 Android 2 API 7 apps 7 autocomplete 2 beginner 173 CAPTCHA 1 Chrome 2 cms 1 crawling and indexing 158 encryption 3 events 51 feedback and communication 83 forums 5 general tips 90 geotargeting 1 Google Assistant 3 Google I/O 3 Google Images 3 Google News 2 hacked sites 12 hangout 2 hreflang 3 https 5 images 12 intermediate 205 interstitials 1 javascript 8 job s
URLの正規化ができていないよく見かける4つのケース | エンジニアのためのSEO入門
Web担当者さんへ システムで生成していないページでもURLの正規化は重要な要素です。今一度自分のサイトで正規化できてない個所がないか、アクセス解析などのデータをチェックしてみてください。正規化とは「正規化」とは、システム開発の世界でデータベース設計に関連してよく利用される言葉ですが、これをSEOの世界に置き換えてみると、大きく以下の2つの意味になります。 そのキーワードを表すURLは、そのサイト内で1つのみ存在するそのコンテンツは、そのサイト内で1つのみ存在するユーザーが検索キーワードを入力すると、検索エンジンはインデックスされている全ドメインから1～2つのURLをピックアップして、順番に並べて表示します。SEOの対象となる、自然検索（オーガニック検索）結果表示エリアへの露出に関しては、1サイト（=1ドメイン）につき、最大2つのページしか表示されません（Googleではこれをクラスタリン
URI変えるな，ページ消すな | Okumura's Blog
探し物をしていて古いリンクをたどったら 総務省｜ご案内ページ －掲載期間が終了しています－ というページにリダイレクトされてしまった。総務省サイトの掲載期間は原則3年で，パンフレットなどは最新版以外は消しているという。国の貴重な資料は永久保存でいいと思うのだが，なぜ消すのだろう？ Webの開祖Tim Berners-Leeは1998年に Cool URIs don't change（神崎さんの訳：クールなURIは変わらない）を書いて，URI（URL）が永続すべきことを説いている。もう10年以上も前のページだが，サイト管理者はぜひ読んでほしい。ここに書いてあるように，何十年も永続させるためにはいろいろな工夫が必要だ。例えば拡張子はその時点での技術を反映する。hoge.html は hoge.cgi や hoge.php や hoge.rb になるかもしれない。そのため，W3Cサイトへの正式な
CRUD型RESTの欠点と、読み取り可能なURI - winplusの日記
「CRUD型RESTの欠点」として挙げられている以下の点。 外部に見せているのは内部的なデータベース構造ないしデータであって、考え抜かれた契約ではありません。 本当のサービスを迂回して直接データにアクセスすることを助長します。 CRUDはRESTにとって良くないのか？ テーブルを知らないとSQLは使えない訳で、それをそのままマッピングするのはテーブルを公開しているのと同じ。これを利用するには、クライアント側が、すべてのビジネスロジックを把握する必要がある。 羊の皮をかぶったクライアント−サーバでしかありません。 CRUDはRESTにとって良くないのか？ 確かにね。 ちゃんとしたRESTfulなWebサービスであれば、クライアント側は一切のビジネスロジックを把握する必要がなくなると。そうであれば、必要かつ十分なWebサービスは、すべてハイパーリンクで提供される。つまり、クライアントがハイパー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ): 山本陽平: 本
rest-discuss : Message: Re: [rest-discuss] Newbie REST Question
rest-discuss : Message: Re: [rest-discuss] Newbie REST Question
query_string - 素人がプログラミングを勉強していたブログ
