Я пишу угловое приложение 1.5, которое полагается на службу REST. В некоторых потоках служба запрашивает у клиента URL переадресации, привязывает к нему параметры и отправляет URL-адрес пользователю.RFC действительный URL для приложений SPA (угловой)
Для большинства клиентов услуги с использованием Params запроса, поэтому если дан:
www.myapp.com/myState
возвращает
www.myapp.com/myState? myParam = значение
Но для angul соток приложение, если дано:
www.myapp.com/#/myState
возвращает
www.myapp.com/?myParam=value#/myState
и что нарушает маршрутизацию приложения.
Это происходит, поскольку в соответствии с RFC http://tools.ietf.org/html/rfc3986#section-4.1 все, что следует за значком #, считается фрагментом URL-адреса и должно быть в конце URL-адреса.
Я вычитаю, что параметры запроса углов не являются точными RFC юридическими, и на самом деле являются своего рода «фрагментными параметрами».
Итак, каков правильный, общий способ создания URL-адресов, который будет использоваться различными типами клиентов: мобильным, веб-сайтом, SPA и т. Д. И до сих пор является RFC действительным?
так ты предлагаешь, что 'myParam' оценивается на стороне сервера, и что' myState' оценивается на стороне клиента? это единственный способ, который продемонстрировал бы ваш пример. – Claies
@Claies это именно он. Поскольку угловой не может читать ничего, что предшествует #, он фактически использует идентификатор фрагмента для прохождения параметров –
«не могу прочитать» не совсем верно; Сервер, игнорирующий данные, следующие за '#', является более точным. Это не проблема, которую может решить угловой. Мне кажется, что у вас есть * несколько угловых приложений, каждый из которых доставляется на определенную страницу на основе ответа сервера, и каждый из этих «мини-спа» передает некоторую внутреннюю маршрутизацию. Если вы не можете консолидировать приложение в одном спа-центре без параметров сервера, единственным вариантом, возможно, будет какая-то утилита перезаписи сервера. – Claies