Как отличается маршрутизация пользовательского интерфейса клиентской стороны с маршрутов на стороне сервера

Question

Когда я создаю успокоительный API с веб-API asp.net, должен ли я иметь в виду, что моя клиентская сторона имеет дело с дизайном URL, представляющим конечный автомат?

Чтобы сделать его более понятным, я также говорю об отношениях сдерживания в URL-адресах.

Например:

У меня есть пользователя объект, который может иметь много Schooylear сущности. У меня есть Schooylear объект, который может иметь много Период объектов.

В результате получается три веб-контроллера API. UserController, SchoolyearController, PeriodController. Теперь я спрашиваю мой сам я должен выставить маршруты, как:

api/users/1/schoolyears/2013-2014/periods/2014-01-01 

вопрос будет теперь, как я должен отобразить маршрут HTTP ???

Я никогда на самом деле не видел маршруты, как один из приведенных выше, скорее, маршрутов, как:

api/users/1 
api/schoolyears/2013-2014 
api/periods/2014-01-01 

НО выше маршрут с вмещающими отношениями будут действительно полезны для пользователя если он виден в строке URL-адрес ...

OR должен ли поддерживающий API не предлагать дизайн URL-адреса, представляющий конечный автомат? Вы видите, что я смущен, когда начинается ответственность клиента или заканчивается сервер ...

Answer 1

Когда вы оптимизируете для клиента с клиентом с поддержкой состояния, используя фреймворк, такой как angularjs, тогда ваши сложенные/вложенные представления будут определять структуру вашего URL-адреса `s. Вам не нужно ничего делать на сервере. Просто продолжайте свою маршрутизацию:

api/users/1 
api/schoolyears/2013-2014 
api/periods/2014-01-01 

как пожелаете. Эти маршруты не имеют ничего общего с состоянием клиента, эти маршруты перенаправляют запрос клиента не более.

На стороне клиента вы создали маршруты с заполнителями, которые customerId`s

или

orderId`s. Когда вы теперь меняете клиента в поле со списком, вы можете обновить свой маршрут с помощью нового выбранного клиента и перейдите к нему, чтобы выполнить соответствующие заказы.

что вы делаете на стороне клиента, просто изменив URL без редиректа:

jquery: change the URL address without redirecting?

Вы просто создать "URL" после того, как хэш, как #/клиентов/1/заказы/2

Если вы не любите hashbang вы можете также пойти на html5 нажимного состояния:

http://badassjs.com/post/840846392/location-hash-is-dead-long-live-html5-pushstate

Answer 2

РЗ Система STful не волнует, как выглядят ваши URI.Веб-структуры заботятся о вашей структуре URI. Желание использовать ваш URI как часть «UI» является серьезной проблемой.
Наличие более длинных URI с несколькими параметрами пути не было самым простым в веб-интерфейсе v1. С помощью маршрутизации атрибутов это должно быть проще.

Единственное, что вам нужно проявлять осторожность, это генерировать иерархии, где один и тот же концептуальный ресурс появляется в нескольких местах иерархии. Это не очень хорошая идея для кэширования.

Вы не хотите быть в ситуации, когда у вас есть,

api/users/1/schoolyears/2013-2014/periods/2014-01-01 

И

api/users/1/periods/2014-01-01