Управление состоянием просмотра с помощью нескольких объединенных ресурсов REST - PullRequest
0 голосов
/ 27 января 2010

Скажем, например, я бы написал форум, который будет выглядеть в браузере следующим образом:

- original post
  - Re: original post 
    - Re^2: original post
    - Re^2: original post
  + Re: original post
_______________________________________________________________________________

Text of the selected post.

Древовидное представление будет одним ресурсом, текст выбранного сообщения будет одним, а окружающая страница будет одним. Если выбран другой пост, страница дыры должна обновляться, чтобы в браузере всегда отображались правильные URI. Но если страница дыры обновляется, клиентское состояние дерева теряется. Ресурс дерева перезагружается, и информация о том, какие узлы расширяются, как далеко я прокручивался и т.п., теряется.

Какой способ REST решить эту проблему?

  • Использовать такие URI как http://some.where/post/123#someTreeInfo и выполнять только частичные обновления страницы? Информационная часть дерева может стать довольно большой.
  • Создать полный ресурс и скрыть тот факт, что есть базовый ресурс, как дерево? Но это не спасло бы древовидное состояние.
  • Передать текущее состояние просмотра на сервер и вернуть его с ответом?
  • Использовать куки?
  • Ждать HTML 5?

Другие идеи? Рекомендации?

1 Ответ

1 голос
/ 27 января 2010

Если у него есть URI, это ресурс. Таким образом, ваша страница, содержащая весь этот контент , является ресурсом , полная остановка, в ReST и в старом добром HTTP. Как таковой он живет сам по себе, независимо от того, что вы можете использовать на сервере для создания своей страницы.

Если, однако, вы хотите обслуживать свою страницу и использовать ajax-вызовы для обновления контента, то вы сразу перейдете к каждому из упомянутых вами ресурсов, чтобы получить их текущую версию. На этом этапе вы можете использовать хеш-тег (как в первом пункте), чтобы сделать URI-копирование удобным для копирования. Или вы можете использовать скрытый iframe, чтобы обеспечить правильную работу навигации в браузере. Оба обычно используются в комбинации. В этом случае текущее состояние страницы либо (или оба) в javascript или (и) в хеш-части вашего URI.

Обратите внимание, что сама страница по-прежнему является независимым ресурсом, и поэтому любое представление "состояние", которое вы передадите перед тем, как хеш создаст новый URI. Если вы не укажете разумно Content-Location, прокси и кэши будут рассматривать их как разные ресурсы полностью.

В сценарии, где вы обрабатываете весь пользовательский интерфейс на сервере перед созданием разметки, полагаться на куки просто зло. Это нарушает веб-архитектуру, нарушает кеширование и т. Д. Если вы хотите использовать его в качестве постоянного хранилища с javascript, и если сервер не смотрит на него, и он чисто косметический, тогда помогите себе.

В этом смысле локальное хранилище в html 5 решит ту же проблему с большим количеством места.

...