問題タブ [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.
api - 次のうち、より適切な REST URL はどれですか?
簡単な質問です。次のうちどれがより良いRest API URLになりますか?その理由は?
GET shop/department/{id}/{action}
GET shop/department/{action}/{id}
アクションは動詞であり、次のいずれかになります。
GET shop/department/{id}/download
GET shop/department/{id}
GET shop/department/{id}/receive
javascript - AJAX はハッシュタグ /#!/ を使用する必要がありますか?
URL 形式http://www.example.com/module/contentを持つ Web ページを作成しました。 これは非常に動的な Web ページであり、実際には Web アプリケーションです。
可能な限りレスポンシブにするために、通常のページ要求の代わりに AJAX を使用したいと考えています。これにより、JavaScript を使用してレイヤーを追加し、オフライン機能を提供することもできます。
私の質問は次のとおりです。URL はどのように作成すればよいですか? それらはhttp://www.example.com/module/contentまたはhttp://www.example.com/#!/module/contentである必要がありますか?
以下は、両方向の私の考えです。これについてすでに明確な考えがある場合は、読む必要はありません。
新しい HTML5 標準に対応したいので、最初のバージョンを使用したいと考えています。使いやすく、URL も見栄えがします。しかし、もっと重要なことは、これを行うことができるということです:
ユーザーがページを要求すると、完全な HTML ページが返されます。
ユーザーがリンクをクリックすると、コンテンツのみが AJAX 経由でコンテナー div に挿入されます。
これにより、JavaScript を使用していないユーザーが私の Web サイトを使用できるようになります。JavaScript を使用する必要がないため、単純に古い「リンクをクリックしてリクエストし、HTML ページ全体を取得する」アプローチを使用するだけです。
これは素晴らしいことですが、問題はもちろん Internet Explorer にあります。IE の最新バージョンのみが履歴 API をサポートしており、これを古いバージョンで機能させるには、ハッシュタグを使用する必要があります。(私のユーザーの 50% は IE を使用することになるので、サポートする必要があります...) そのため、/#!/ を使用して動作させる必要があります。
これらの両方の URL バージョンを使用すると、IE ユーザーがこのリンクを Web サイトに投稿すると、Google がサーバーに _unescaped_string (または類似の文字列) を送信するという問題が発生します。ハッシュタグ。また、一部のページにはハッシュタグがありません。
そして、私たちが覚えているように、非ハッシュタグは多くの異なる点で優れています. では、この検索エンジンの問題は回避できるのでしょうか? ウェブサイトのハッシュタグ バージョンに到達している場合、ウェブページの非ハッシュタグ バージョンにリダイレクトする必要があることを GoogleBot に伝えることは可能ですか? このようにして、非ハッシュタグ URL の利点をすべて享受しながら、IE6-IE9 をサポートすることができます。
最善のアプローチは何だと思いますか? 多分あなたは実際にそれを自分で試しましたか?ご回答有難うございます!
rest - 残りの設計原則
以下は、顧客のすべてのサブスクリプションを一覧表示するための適切な残りの設計手法ですか。
[BaseUrl]/subscriptions/[accountid]/payTV
[BaseUrl]/subscriptions/[accountid]/paywall
など...
またはそれはむしろあるべきです:
[BaseUrl]/subscriptions/payTV?[accountID]
[BaseUrl]/subscriptions/paywall?[accountID]
など...
または、他の何か?
http - WebサイトもWebリソースである必要がありますか?
すべてのWebアプリケーション(すべてのWebサイト)はサービスです。(...)WebサイトをWebサーファーが使いやすくする機能により、WebサービスAPIもプログラマーが使いやすくなります。
リチャードソンとルビー、「RESTFulWebサービス」
私が意図しているように、WebサービスでもあるWebサイトは、ユーザーエージェントが何を要求するかに応じて、そのリソースの複数の表現を提供します。APIは、いわばWebサイト自体であり、個別に提供されるものではありません。
これは、世の中に出回っている多くの人気のある「RESTAPI」には当てはまりません。たとえば、TwitterのAPIはhttp://api.twitter.com/1/にあり、URIの「1」はAPI自体のバージョンです。Socialcastは、 https: //demo.socialcast.com/api/でREST APIも提供します。第3レベルの名前は、アドレス指定するネットワークの名前です。
これは私には間違っているようです。http://www.example.com/blogにブログがある場合、ロボット専用のJSONを提供するために、別の場所にAPIを提供する必要はありません。http://www.example.com/blog/posts/とhttp://api.example.com/blog/postsの2つの異なるURIを使用する代わりに、前者だけを使用し、複数の表現を使用できるようにする必要があります。application/json
ユーザーに提供したいJSONAPIの場合。
例1:私のブログへの投稿を要求するブラウザ。
リクエスト:
応答:
例2:同じURIですが、今回はロボットがリクエストを行います。
リクエスト:
応答:
APIのバージョン番号は、リクエストヘッダーの「Accept」フィールドにエンコードする必要があります。特に、TwitterのようにURIを強く入力することは避けてください(「statuses / show.json?id=210462857140252672」または「statuses/show / 210462857140252672.json ")。
統一されたアプローチを採用することで柔軟性を失う可能性がありますが(ただし、Cool URIは決して変更されるべきではありませんか?)、REST(または少なくとも私の解釈)を順守することでより多くのメリットが得られると思います。
APIとWebサイトを分離するか、それらを統合するか、どちらがより正しいアプローチですか?
http - トリプルをパラメーターとする REST リソース
有限のパラメータ セットを使用する URL を作成する必要がある場合、そのパラメータのすべてが意味的に同じ「レベル」である場合、URL 内の区切り文字の使用に関する現在のコンセンサスは何ですか? 次に例を示します。
つまり、ここでのパラメーターは、シングル、ペア、またはトリプルである可能性があります。これらは論理ツリーではなく、thing2 は thing1 の下位リソースではないため、任意の順序で指定できます。
これは、トリプルの要素間のツリーのような関係を意味するため、私を悩ませますが、そうではありません (多くの HTTP フレームワークがこれを推進しているように見えますが、私の見解では間違っています)。さらに、これは検索操作ではないため、クエリ文字列を使用するのは適切ではありません。これは、非常に限られたスペース内の既知のトリプルです。いわば、クエリまたは検索するものは何もありません。
他のオプションは、それをPOST
リクエストにして、提供されるトリプルの部分を詳述する本文を提供することだと思います. ただし、何らかの理由で、これは私に暖かいファジーを与えません。
他の人はこれをどのように処理しましたか? 区切り文字は私にはきれいに見え、リソースの意図されたセマンティクスを伝えますが、別の見方をする人がいることを知っており、同様のユースケースを経験した他の人の経験を理解しようとしていました.
url - 正規 URL とローカリゼーション
私のアプリケーションでは、次のようなローカライズされた URL があります。
- http://examle.com/en/animals/elephant
- http://examle.com/nl/dieren/olifant
- http://examle.com/de/tiere/elefant
この質問は主に Facebook の Likes に関するものですが、検索エンジンのクローラーについて考え始めると、同様の問題にぶつかると思います。
正規の URL としてどのような URL を期待しますか? リンクをクリックした人が自分の言語に転送されるようにしたいので(ブラウザ設定/ IPに依存) 、正確な英語のURLを使用したくありません。
IP ルックアップは、ページがヒットするたびに実行したいものではありません。それに加えて、ユーザーがすでに自分のロケールに転送されているか、意図的に英語版を閲覧しているかを確認する必要があるため、アプリケーションにさらに「状態」を組み込む必要があります。
私はそれが次のようなものになると思います:
http://example.com/something/animals/elephant
または、言語識別子がまったくない場合:
http://example.com/animals/elephant
しかし、それは実装が少し難しく、将来的に URL が衝突する可能性が高くなります (まれにenまたはdeというカテゴリを取得します)。
概要
正規の URL としてどのような URL を期待しますか? このための標準セットはすでにありますか?
node.js - ルートとパラメーターを決定するための重要な要素は何ですか
ルートの 2 つの因数分解を決定する根拠がわかりません。私の質問は、次のいずれかを決定するための鍵となる要因は何ですか。
- より多くのルート - より少ないパラメーター
- より少ないルート - より多くのパラメーター - ハンドラーのロジック
以下の 2 つのサンプルは私の実際のケースですが、これは一般的な質問だと思います。
私のベースラインは、それぞれ 2 つのパラメーターを持つ 2 つのルートです。
代替ファクタリングは、3 つのパラメータを持つ 1 つのルートです。
この 2 つは、私にはほぼ等しいように見えます。違いは、ルーティング テーブル内の 1 つのブランチと、mymodule 内の 1 つの if ブランチです。これらのファクタリングのいずれかを支持してバランスを傾けるキャッシング、メモ化、またはその他の要因はありますか? クライアント側は要因に貢献していますか?