問題タブ [url-design]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
url - URLの区切り文字として「+」または「-」?
ほとんどのウェブサイトは-
(Stack Overflowのように)使用しますが、ほとんどのPHPフレームワークは+
エンコードされたURLを生成します。
それで、SEOに最適なものは何ですか?+
または-
セパレータとして使用しますか?
ruby-on-rails - RESTful な Q&A 設計?
これは私が現在取り組んでいるおもちゃのプロジェクトです。
私のアプリには、複数の選択肢の回答を持つ質問が含まれています。
質問の URL は次の形式で、GET
&POST
は質問コントローラーのさまざまなアクションにマッピングされます。
これを RESTful スタイルに再設計する価値があるかどうか疑問に思っています。リソースとして回答を紹介する必要があることはわかっていますが、その質問に回答するのに自然に見える URL を考えるのに苦労しています。
再設計する価値はありますか?URL をどのように構造化しますか?
url - URL で言語を表示するのに最適な場所はどれですか?
検索エンジンに適した URL と呼ばれるきれいな URL を使用する多言語 Web サイトがあります。
URL で言語を定義する場所がいくつかあります。
www.example.com/en/articles/random
www.example.com/nl/articles/random
en.example.com/articles/random
nl.example.com/articles/random
www.example.com/articles/random?lang=en
www.example.com/articles/random?lang=nl
これを示す好ましい方法はありますか、それとも私が含めなかった別のより良い方法はありますか?
asp.net - オプションの開始パラメーターを使用したasp.netmvcルーティング
既存のASP.NETWebフォームCMSからASP.NETMVCへの移植を開始しており、最初から正しくルーティングを取得したいと考えています。
注:まったく同じURL構造を持つことは重要ではありません。
この答えは私が探しているものに近いと思いますが、誰かがそれを持っている場合は、いくつかの追加の入力が必要です。
現在のURL構造は次のようになります。
?Content = News / CurrentNews / This_is_a_news_article
?Content = Corporate / About_Us / Overview
などなど
オプションの言語パラメーターを追加し、MVCで同様の構造を維持したいと思います。だから次のようなもの:
News / CurrentNews / This-is-a-news-article
en / News / CurrentNews / This-is-a-news-articleedit / News / CurrentNews / This-is-a-news-article
edit / en / News / CurrentNews / This-is-a-news-article
または私は逆の方がいいですか?
News / CurrentNews / This-is-a-news-article / edit
en / News / CurrentNews / This-is-a-news-article / edit
この方法(最後にアクションを使用)では、私が読んだ他の質問からすべてのシナリオのルートが必要になると思います。
もう1つのポイントは、既存のURLがSEOやパンくず生成の場合と同じように行われることです。つまり、URLは現在のナビゲーションパスを示します。
URLに現在のページを表示し、データベースからパンくずを個別に作成することができます。
好き:
en /This-is-a-news-article
クラム付き
ホーム>ニュース>現在のニュース>これはニュース記事です
全体的な考えと解決策?最大限の柔軟性を得るために、カスタムルーティングクラスから始める必要がありますか?
drupal - Pathauto のメニュー パス
Drupal 7 で pathauto を取得して、フル メニュー パスで URL エイリアスを生成するにはどうすればよいですか?
url - URL で末尾のスラッシュを使用する必要があるのはいつですか?
URL で末尾のスラッシュを使用する必要があるのはいつですか? たとえば、私の URL は のように見えます/about-us/
か/about-us
?
私は SEO 関連の問題を十分に認識しています - コンテンツの重複と正規のもの。ページを単独で正しく提供するというコンテキストで、どれを使用する必要があるかを理解しようとしています。
たとえば、私の同僚は、末尾のスラッシュは「フォルダー」または「ディレクトリ」を意味すると考えているため、これは正しいスタイルではありません。しかし、最後にスラッシュがないと思います-それはほとんどフォルダーのように見えるため、まったく正しくありませんが、そうではなく、通常のファイルでもなく、拡張子のないファイル名です。
どちらを使用するかを知る適切な方法はありますか?
url - URL 構造のベスト プラクティス / 標準
アイテムを含むサイトを構築しています。各アイテムにはページがあります。次に例を示します。
各アイテムには複数のサブ (およびサブサブ、サブサブサブ) ページを含めることができます。たとえば、本には宣伝文句があり、映画にはギャラリーがあり、ゲームにもギャラリーがあります。
私の質問は、アイテムに関連付けられたページの URL の構造化に関して、何らかの標準またはベスト プラクティスが存在するかどうかです。例えば:
サブページがアイテムの後に来る場所、または:
item は URL の最後の部分です。
どのアプローチが最適なのか、または Web 標準が存在するかどうかについて、誰かが情報を持っていますか? 当然のことのようですが、決めるのに苦労しています。各アプローチの長所と短所を考えることができます-次のユーザーパスがURLと一致することを意味するため、前者のオプションに傾いています:
website.com をロード -> 「映画」をクリック (website.com/films) -> 「映画」をクリック (website.com/film/123) -> ギャラリーをクリック (website.com/film/123/gallery)
しかし、それについての何かが... オフで、一貫性がないように思われます。
url - 階層URLとフラットURL
フライト>座席>予約のようなリソース構造があるため、予約は特定のフライトに属する特定の座席に属します。
顧客は後でキャンセルするためにこの(やや醜い)URLを取得するので、リソース構造を省略し、予約へのリンクを短くすることを検討します。
このURLを短縮しない理由(ユーザーに関連する)はありますか?
rest - フラットな URL よりも、追加のオーバーヘッドという点で、階層的な RESTful URL が依然として好まれるのでしょうか?
ユーザーが自分の写真をアップロードして表示できる Web サイトがあるとします。そのユーザーの単一の写真への RESTful URL は次のようになります。
しかし、image-id 自体はすでに一意であるため、この URL で十分取得できます。
REST の観点からは、最初のものは有利ですが、この画像が本当にこのユーザーからのものであることを確認する必要があります。後者の場合、このチェックを追加する必要がないため、処理時間が短縮されます。
そのような場合でもRESTfulであることは好まれますか?
url - ウィキペディアがURLフラグメントで変更されたパーセントエンコーディングを使用するのはなぜですか?
ウィキペディアがURLのパスセクションにパーセントエンコーディングを使用しているのに気づきましたが、%
文字を.
#fragmentに変換します。
たとえば、ロシア語の「ロシア」ページでは、セクション2(История)のURLは次のとおりです。
http://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F#.D0.98.D1.81.D1.82.D0.BE.D1.80.D0.B8.D1.8F
それ以外の
http://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F#%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F
トークンは[A-Za-z]で始まる必要があるため、ID/名前に有効なHTML<5トークンもありません。HTML5は現在、スペース以外の任意の文字の少なくとも1つを使用できると述べています(したがって、エンコードする必要はまったくありません)が、ウィキペディアはHTML5ではありません。
では、なぜウィキペディアがこのスキームを使用したのでしょうか。