API デザイン : URL には名前と識別子のどちらを使うべきか | Google Cloud 公式ブログ
ウェブ API の設計に携わっている方であれば、API で使う URL のスタイルに統一的な考え方がないことも、選択した URL スタイルが API の使いやすさや寿命に大きな影響を与えることも、よくご存じでしょう。Google Cloud の Apigee チームは、社内だけでなくお客様とも協力しながら、API の設計について長く検討を行ってきました。本稿では、私たちが設計の現場で実際に使用している URL のデザイン パターンと、それを使う理由についてシェアしたいと思います。 著名なウェブ API をご覧になれば、いくつかの異なる URL パターンがあることに気づかれるはずです。次に示すのは、極端に異なる考え方に基づいた 2 つのスタイルの具体例です。 https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7 htt
QiitaのURL構造が変更され、エゴサーチしやすくなりました - Qiita Blog
привет! (ロシア語でこんにちは） 梅雨で癖っ毛に磨きがかかっている yuku_t です。 さて、昨日Qiitaの各ユーザページと投稿ページのURLが変更されました。 まずユーザページは下記の様に ‘/users’ が無くなりました。セクシーですね！ （旧）http://qiita.com/users/yuku_t（新）http://qiita.com/yuku_t次に投稿ページのURLに投稿者のユーザ名が含まれるようになりました。エレガントですね！ （旧）http://qiita.com/items/40b7daf018d3dab48974（新）http://qiita.com/yuku_t/items/40b7daf018d3dab48974この結果ユーザ名によるエゴサーチ（自分で自分のことを検索すること）でQiitaがより引っ掛かりやすくなりました。 また、各投稿の投稿者に対す
技術/HTTP/URLエンコードで 0x20(スペース) を "+" にすべきか "%20" にすべきか - Glamenv-Septzen.net
id: 1170 所有者: msakamoto-sf 作成日: 2013-03-23 22:18:13 カテゴリ: HTML HTTP ネットワーク [ Prev ] [ Next ] [ 技術 ] ※時間がないとか、だらだらとRFCの解説を読んでる暇が無い方は、末尾のまとめ部分だけ目を通していただければ十分かと。 URLのpath中やquery中、POSTリクエストボディ中で、0x20のスペースを、"+"に変換するのが「正しい」のか、"%20"にするのが「正しい」のか、わからなくなってきたのでちょっと調べてみました。 ただしRFCの全文を熟読してるわけではないので、言い回しや表現はもとより理解そのものが間違ってる可能性もあるので、話半分程度に参考にしてください。 "+"を使うべきか、"%20"を使うべきか、よく迷う箇所： URLのパス中 URLのクエリ中 "application/x-w
RailsアプリでURLにidじゃなく、任意文字列でアクセス出来るようにしておく - Qiita
ルーティングルールのresourcesやmemberなどでURLに:idを伴うときに、多くの場合PrimaryKeyを使ってしまいがちですが、将来、要望として任意の文字列で代用したい。なんてことが考えられるので、簡単に修正ができるように備えておきます。 URLに:idを含むとき。
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
XPathでRESTfulなURL設計を考えてみる
WebAPIまたはWebサービスを作るときに、考えないといけないのがURL設計です。 近年は「Cool URL」と称して、短いURLを設計するのが流行りです。例としては、twitterの各ユーザーページのURLは「/user?user={ユーザーID}」などではなく、「/{ユーザーID}」になっています。 例：http://twitter.com/Hiraku 究極に短いURLですね。 ただ、ここまで短くしてしまうと困ることがあります。 twitterの場合だと、検索用のURL「/search」やオプション設定の「/settings/...」などは特例であり、ユーザーIDを指していません。これは、searchやsettingsという名前のユーザーを作ることができないことを意味します。拡張性が犠牲になってしまったんですね。。。 twitterほど極端なURL設計にせず、わかりやすく、自然に設
JavaScriptによるRFC6570 - URI Templateの実装 - とあるプログラマの日記 @s025236
JavaScriptで実装したのがdraftレベルのしか見つからなかったので作ってみました。 (↑Lv4まで対応してるのが有りました。でもせっかく作ったので引き続き公開しておきます。) URI Templateって？ 簡単に言うとURIに特化したテンプレートエンジンです。 「http://www.example.com/users/{userid:1}/{userid}/」って書いといて「http://www.example.com/users/t/test/」って文字列作れたら便利だよね！？ 詳しくは以下を参考にしてください。 RFC 6570 - URI Template 3分間・URIテンプレート - 檜山正幸のキマイラ飼育記 (はてなBlog) URI Templates の各言語実装 - Mi manca qualche giovedi`? 以下からお持ち帰りください。 gith
URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する
friendly_idを使ってFriendlyでRESTfulなURI設計 - Qiita
Rails 3から resources というルーティング・ヘルパが用意されてRESTfulなURI設計に非常に役立ちます。 しかしながらサロゲートキーをプライマリキーに据える設計が主流のRails界隈において、データベースのプライマリキーをメンバURIのキーに採用するという戦略は /users/4 といった無味乾燥で、またわかりやすさに欠けるURIを生んでしまう弊害もあります。 たとえばユーザを表すリソースがあったとして、それらを一意に定めるのは名前が考えられます。 つまり /users/aereal や /users/aereal/edit といったURIで表現したいです。 RailsのRESTfulなパス・ヘルパ (user_path など) のうちメンバ・リソースに関するヘルパについてはオブジェクトを渡すと暗黙のうちに Object#to_param が呼ばれます。 これをオーバー
HTTPのクエリパラメータにコロン(:)を書くのは不正なのか。 - こせきの技術日記
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
URL, ブログモード推奨の啓蒙 - Sexually Knowing
はてなダイアリーやtDiaryの日記モード、1日のうちに複数投稿するとセクションで隔てられるけど、それを参照する有効なHTTP URLがないのがすごく不便。 セクションはひとつのリソースとして独立性が高いし、locatableであるべきだとおもう。 日記モード (日付ごとのリソースまでがlocatableで、セクションはlocatableではない) を使うメリットは薄いし、デメリットはとてつもなく大きい。 (有効なHTTP URLがないことによる損失をユーザもはてなも鑑みるべきでは……) crawlable-hashとかもdisられたけど、WWWの根幹を揺るがすような変更には慎重になるべきだとおもう。
REST-ful URI design | RedRata
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:/
見やすいJavaScriptコードのために。クライアントサイドのルーティングライブラリ·SugarSkull MOONGIFT
SugarSkullはJavaScriptによるクライアントサイドのルーティングライブラリ。 SugarSkullはjQuery/JavaScript製のオープンソース・ソフトウェア。RailsやSinatraが普及した要因の一つにルーティングがあげられる。それまではクライアント側のURLとサーバ側で実際に動作するプログラムとが乖離していた気がするが、それがぴったりとくっつく存在になったのだ。 デモ Sinatraの普及もあって、他のプログラミング言語でもルーティングに力を入れるようになった。それはサーバサイドに限らずWebクライアント側でも同じだ。JavaScriptでルーティングを行うのがSugarSkullだ。 SugarSkullはaタグの指定するURLでルーティングを可能にするライブラリだ。通常、デザインとJavaScriptを分離するためにはidやclassを使ってアクションを
URLにはハイフンか、アンダースコアか。 – SEOメモ | find a way ! ウェブマネジメント
Wordpressで、記事のスラッグ(URLの一部)を手入力なんかするときに、 ハイフン「-」にすべきか、アンダースコア「_」を使うべきか、 なんとなくアンダースコアばかり使用してましたが、 ハイフンとアンダースコアはそれぞれ意味が違うようです。 「ハイフンとアンダースコアは検索エンジンに対する意味合いが異なります。 ハイフンは文字通り単語を分離するために使われる記号なので、 ハイフンの前後の単語は個別のキーワードとして認識されます。 逆に、アンダースコアは前後の単語を連結するので、 アンダースコアも含めた1つのキーワードとして認識されます。」 （「URL最適化5つのSEOポイント」ウェブ担当者フォーラムより） なるほど、そうやって使い分けるのか。 ほかにも知らないことがたくさん載ってて参考になりました。 ウェブ担フォーラム元記事もぜひどうぞ。 ウェブ担当者フォーラム ht
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tkawa/resources_id_replace: Replace param name of resources' id for Rails
URLで遊ぼう
#314 Pretty URLs with FriendlyId - RailsCasts
Hashbang Conversation (with tweets) · timhaines · Storify
Home | Nidhis
はてなブログがはてなダイアリー以外のブログサービスより優れているたったひとつの理由 - @kyanny's blog
