URL обработка в гипермедиа (HATEOAS), приводимое AngularJS применение

Question

Мы ищем некоторые советы по работе с URL-адресов (и состояние, связанное с каждой URL) в вебе-приложении, подкрепленной API HATEOAS REST, более конкретно на

• как избежать URL-адреса веб-приложений в сочетании с REST API URL-
• как обрабатывать несколько ресурсов в одном представлении

Но позвольте мне сначала обеспечить более некоторый контекст:

Мы строим приложение углового веб-сайта поверх слоя REST с ограничением Hypermedia. (Примечание. Я предпочитаю просто использовать термин «Гипермедиа (ограничение)» над HATEOAS).

Как указано в ограничении Hypermedia, доступные действия и ссылки в приложении в любой момент времени предоставляются API REST. Таким образом, веб-приложение не должно содержать никаких жестко запрограммированных URL-адресов REST API, за исключением «root» (если предположить, что концепция действительно существует в REST API).

С другой стороны, каждая страница в веб-приложении должна быть заклассифицирована. Поэтому мы не можем создать приложение с черным ящиком (с единственным URL-адресом и всеми изменениями состояния, которые обрабатываются в SPA без изменения URL-адреса). Это означает, что веб-приложение также имеет свое URL-пространство, которое необходимо каким-то образом сопоставить с URL-адресом URL-адреса REST API. Это уже конфликт с идеей Hypermedia.

В Угловом приложении мы используем UI Router для управления состоянием приложения. Вот как мы получили это работает:

• Мы только определить состояния, не URLS
• Мы определили обработчик $ urlRouterProvider.otherwise который будет отображать текущий URL веб-приложения к corrsponding REST API URL, получить представление ресурса, который соответствует этому URL REST и передает его контроллеру (в $ stateParams).
• Контроллер может затем использовать эти данные (и ссылки и действия) в представлении, так же, как это было бы, если бы сделал REST называть себя (или через службу)

До сих пор так хорошо (или нет на самом деле), потому что есть некоторые недостатки этого подхода:

• URL-адреса веб-приложения отображаются в REST API URL, так как URL пространства связаны между собой, что противоречит одной из основных предпосылок использования HyperMedia ограничения : мы не можем изменить URL-адрес API REST без изменения веб-приложения.
• В обработчике $ urlRouterProvider.otherwise мы получаем представление текущего URL-адреса веб-приложения. Но в некоторых случаях у нас есть два ресурса в одном представлении (с использованием вложенных состояний UI Router): например, список элементов и деталь одного элемента. Но есть только один URL-адрес, поэтому восстанавливается только представление детали элемента, а список элементов остается пустым.

Поэтому мы хотели бы услышать некоторые предложения о том, как мы могли бы улучшить наш подход при обработке двух URL-адресов. Есть ли лучший способ сделать REST API диктующим (доступным) поведением веб-приложения и все еще иметь URL-адреса закладки в веб-приложении? Потому что теперь у нас есть гибридный подход, который не чувствует себя совершенно правильно.

Заранее спасибо.

С уважением,

Люк

Answer 1

, что жесткая установка. Примерно вы хотите добавлять закладки в свой API, а системы RESTful несколько препятствуют закладкам.

Одним из возможных решений является «услуга закладки», которая возвращает URL-адреса закладки (bit.ly like) для текущего ресурса, который гарантированно совместим с будущими ресурсами, поскольку, поскольку вы можете изменить структуру канонического url, служба закладок может всегда переводите bit.ly как url ​​в канонический url. Звучит сложно, но мы постоянно это видим, и мы называем их поисковыми URL-адресами, например:/product-name/maps to products/today, но могут быть/catalog/old-products/tomorrow.

Как вы согласуете это с пользовательским интерфейсом, который показывает 2 ресурса, первым из которых является список итоговых ресурсов, а второй - конкретный ресурс get, который действительно сложный. Я бы ожидал, что такая страница будет содержать состояние того, что она отображает в своем url (вероятно, в фрагменте). Как таковой, поскольку [вероятно] контроллер, который обрабатывает такие команды, вероятно, нуждается как в ресурсе списка, так и в расширенном ресурсе. Я держал пари, что URL будет выглядеть примерно так:

list=http://path/to/list/results&expand=http://self/link/of/path

Так последняя часть у вас есть, чтобы убедиться, что работы ведутся вперед. Опять же это проблема с закладкой. То, что я могу предложить, если вы не хотите создавать службу закладок, состоит в том, что если вы хотите, чтобы такие закладки были необходимы для перехода людей на новые URL-адреса. Когда запрос делается на http://path/to/list/results, и вы хотите переключить его, вы должны перенаправить 301 на новый канонический url, и приложение должно обновлять закладку. такое перенаправление может включать параметр & flag = deprecate_message, чтобы вызвать презентацию в пользовательском интерфейсе, когда закладка клиента устарела и ее необходимо заменить. В качестве альтернативы ответ может быть внутренне переадресован, а флаг отмены & канонической (или последней) ссылки включен в ответ на старый URL. Это приводит к поэтапному переходу.

Подводя итог: Я еще не видел, чтобы HATEOAS был излечим все для назад & передовой совместимости, но это намного лучше, чем существующие методы. что вы все равно должны принимать решения в v1 вашего API о том, как вы хотите, чтобы ваши пользователи переместились на v2.