GET /@:id みたいなURLで他との衝突を避ける - Qiita
Webアプリのルーティングにおいて、各ユーザの個別ページを特殊なものにしたい場合にどういうURLにすると便利かという話に触れる。例えばr7kamuraというIDのユーザ用のページは、Twitterだと https://twitter.com/r7kamura で、GitHubだと https://github.com/r7kamura というURLになっている。 GET /:id だと他のパターンと衝突してしまう もしユーザページに GET /:id というパターンを採用すると、他のURLのパターンと競合してしまうという問題がある。どんなときに困るかと言うと、例えば https://twitter.com/about でTwitterというサービスについて説明するWebページを提供しようとすると、aboutというIDを持ったユーザ用のページが提供できなくなってしまう。 この問題に対してよく
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
DebianのユーザーID(uid)のデフォルト定義 - それマグで！
DebianのユーザーID(uid)は、番号の範囲で用途が明確に決められている。 LDAPやNFSなど複数システムのuidが連携するときに注意が必要です UIDは規則を意識して決めた方がよいと思います。 uid 役割と意味 例 0 - 99 debianシステムユーザーの予約領域 root,www-data,irc 100 - 999 システム・ユーザーの予約領域 mysql,bind 1000 -29999 一般ユーザーが使う takuya,user 30000 - 59999 予約領域 なし 60000 - 64999 debianが一時的に使う なし 65000 - 65533 予約領域 なし 65534 nobody 専用 nobody 65535 使用禁止 - takuyaさんの現在システム 私の環境の例です。 root:x:0:0:root:/root:/bin/bash da
登録されるとつらいユーザー名リスト - Qiita
Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatenablog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブサービスの body 要素に出力されている id と class まとめ · Issue #56 · shikakun/tips
