0
アプリ。いくつかのフローでは、サービスはクライアントにリダイレクトURLを要求し、paramsをアタッチしてURLをユーザーに送信します。RFC有効なURLは、私はRESTサービスに依存している角度1.5アプリを書いて
サービスが与えられたとき、したがって、クエリのparamsを使用しているほとんどのクライアントのために：
www.myapp.com/myState
を
それは
www.myapp.comを返します。/myState？myParam = value
しかし、 ARアプリ、与えられた：
www.myapp.com/#/myState
それは www.myapp.com/?myParam=value#/myState
を返します。
これはアプリのルーティングに違反します。
RFC http://tools.ietf.org/html/rfc3986#section-4.1に応じて＃記号の後に続くすべてはURLフラグメントとみなされ、URLの最後にする必要がありますので、それは起こります。
私は角のクエリのparamsは正確にRFC法的なものではなく、実際には「フラグメントのparams」のいくつかの種類であることを控除します。
それでは、さまざまなクライアントの種類によって使用されるURLのを構築するための正しい、汎用的な方法である：モバイル、ウェブ、SPAなど、まだ、有効なRFCこと？
は、あなたが 'myParam'は、サーバ側で評価されることを示唆している、と' myState'は、クライアント側で評価されていることをしていますか？これは、あなたが投稿した例が意味をなさない唯一の方法です。 – Claies
@Claiesそれはまさにそれです。 angleは＃に先行するものを読み取ることができないので、実際にはフラグメント識別子を使用してパラメータを渡します。 –
「読むことができません」は正確ではありません。 '＃'に続くデータを無視するサーバはより正確です。これは特に角が解決できる問題ではありません。サーバーレスポンスに基づいて特定のページに配信される複数の角型アプリがあり、これらの「ミニスパ」はそれぞれ内部ルーティングを受け持っているようです。サーバーパラメータなしで単一のスパにアプリケーションを統合できない場合、唯一のオプションはおそらく何らかの種類のサーバー書き換えユーティリティです。 – Claies