タグ

developmentとurlに関するLayzieのブックマーク (6)

  • URLs are already dead - Human Who Codes

    Posted at May 6, 2014 by Nicholas C. Zakas Tags: Browsers, Internet, URLs Last week, there was a fair bit of furor when Jake Archibald wrote an article1 describing an experimental feature in Chrome that hides all but the domain name of the URL you’re on. The idea is very similar to what already happens in the iOS 7 version of Safari: once navigation is underway, the URL is hidden and only the doma

  • 短縮URLっぽい文字列の生成方法3つ - 9mの日記

    短縮URLっぽいURLの文字列。http://bit.ly/wEFnVF の場合「wEFnVF」の部分をどうやって生成するかちょっと考えてみたけど、大まかに三通りしかなさそうだというメモ。1.一方向ハッシュ関数MD5とか。この方法が一番手軽な場合けっこうあると思う。ただし、文字数がやたらと多くなってしまうため短縮URLとかでは使えない。 2.適当な文字列ほとんどこれだと思う。ただし、重複チェックが必要になるので生成するたびにDBアクセスが発生するし、桁が上がる直前になると鬼のようにDBアクセスが発生するため工夫が必要。bitlyのように、あとからパスを変えられるタイプは大体これ形式なはず。 3.62進数データベースの連番のidとかを62進数に変換すれば重複なしでスマートっぽくできる。元の10進数の数字を知られたくない場合、下のコードだと@n_mapの文字達を適当にすれば簡単には分からなくな

  • RailsでのURL設計を考えてみる(5) Railsのリソースパターン - ぶろぐ。@はてな

    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

    RailsでのURL設計を考えてみる(5) Railsのリソースパターン - ぶろぐ。@はてな
  • 10 Best URL Shorteners and why they are good | Tripwire Magazine

  • 続・こんなURI 設計、どう? - 岩本隆史の日記帳(アーカイブ)

    先日書いた「こんなURI 設計、どう?」の続きです。 例:商品ブックマークサービス URI設計の例として、商品ブックマークサービスを対象に考えてみます。提供するおもなリソースは、以下の5つです。 リソース名 パンくずリストのイメージ トップレベルリソース トップ ユーザ登録画面リソース トップ>ユーザ登録 ユーザ別ブックマークリソース トップ>iwamotのブックマーク ブックマークリソース トップ>iwamotのブックマーク>Webを支える技術 商品リソース トップ>Webを支える技術 うち商品リソースについては、はてなブックマークのエントリページ(例:http://b.hatena.ne.jp/entry/twitter.com/)みたいなものとお考えください。商品ブックマークサービスでは、entry以下のURI断片の代わりに、Amazonの商品コード(ASIN)を用いることにします。

    続・こんなURI 設計、どう? - 岩本隆史の日記帳(アーカイブ)
  • こんなURI設計、どう? - 岩本隆史の日記帳(アーカイブ)

    先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク

    こんなURI設計、どう? - 岩本隆史の日記帳(アーカイブ)
  • 1