Является ли веб-связь в режиме реального времени несовместимой с парадигмой REST?

В последние годы веб-приложения испытали большой сдвиг в парадигме.

Десять лет назад (и, к сожалению, даже в наши дни) веб-приложения жили только в супертяжелых серверах, обрабатывая все от форматов данных до презентаций и отправляя немым клиентам, которые только отображали вывод сервера (браузеров).

Затем AJAX присоединился к игре, и веб-приложения начали превращаться во что-то, что жило между сервером и браузером.

В эпоху AJAX логика веб-приложений начала полностью жить в браузере. Я думаю, что это было когда HTTP RESTful API начал появляться. Внезапно каждая новая служба имела свой вид RESTful API, и вдруг фреймворки JavaScript MV * начали появляться, как попкорны. Использование мобильных устройств также значительно увеличилось, и REST идеально подходит для подобных сценариев. Я говорю "вид RESTful" здесь, потому что почти каждый API, который утверждает, что является REST, не является. Но это совсем другая история.

Фактически, я стал своего рода "евангелистом REST".

Когда я думал, что веб-приложения не могут развиваться намного больше, новая эра, похоже, зарождается: постоянные веб-приложения с постоянным подключением. Meteor является примером блестящей структуры такого рода приложений. Затем я увидел этот видео. В этом видео Мэтт Дебергалис рассказывает о Метеор, и оба делают фантастическую работу! Однако он как бы сводит REST API для таких целей в пользу постоянных подключений в реальном времени.

Я бы очень хотел иметь обновления модели в режиме реального времени, например, но все еще обладаю всей привлекательностью REST. Потоковое REST API похоже на то, что мне нужно (firehose.io и Twitter API, например), но информации об этом новом виде API очень мало.

Итак, мой вопрос:

Является ли веб-связь в режиме реального времени несовместимой с парадигмой REST?

(Извините за длинный вводный текст, но я думал, что этот вопрос будет иметь смысл только в каком-то контексте)

Ответ 1

Устойчивые постоянные соединения tcp/ip для веб-приложений великолепны, если вы не перемещаетесь.

Я разработал веб-платформу в режиме реального времени, и по своему опыту я обнаружил, что при использовании веб-браузера на основе мобильного устройства IP-адрес постоянно менялся, когда я переходил от башни к башне, или Wi-Fi для Wi- Fi.

Когда IP-адреса продолжают меняться, понятие о том, что это постоянное соединение, испаряется довольно быстро.

Структура веб-приложения в режиме реального времени должна быть сконструирована с учетом предположения о том, что соединения будут временными, и инфраструктура должна реализовать свое собственное представление о сеансе, в то время как базовое IP-соединение с внутренним контентом продолжает меняться.

Как только сеанс был определен и используется во всех запросах и ответах между клиентами и серверами, у одного по существу есть "веб-соединение". И теперь можно создавать веб-приложения в режиме реального времени, используя парадигму REST.

Внутренний сервер фреймворка должен быть интеллектуальным для очереди обновлений, в то время как IP-адреса проходят переходы, а затем синхронизируются при восстановлении соединений tcp/ip.

Короткий ответ: "Да, вы можете делать онлайн-приложение в режиме реального времени, используя парадигму REST".

Если вы хотите сыграть с одним, дайте мне знать.

Ответ 2

Я тоже очень заинтересован в этом вопросе. В этом посте есть несколько ссылок на документы, в которых обсуждаются некоторые проблемы с плохо разработанным RPC:

http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html

Я не говорю, что Метеор плохо разработан, потому что я не знаю много о Метеор.

В любом случае, я думаю, что я хочу лучшего из "мира". Я хочу использовать REST и все, что он предоставляет с ограниченным общим интерфейсом, адресностью, безгражданством и т.д.

И я не хочу отставать в этой "реальной" паутине! Это определенно очень удивительно.

Мне интересно, нет ли гибридного подхода, который может работать:

Конечные точки RESTful могут позволить клиенту вводить пробел и следовать ссылкам на связанные документы, к которым призывает HATEOAS. Но для "потока обновлений" для ресурса, возможно, "имя подписи" само может быть URI, который при просмотре в точечном одиночном запросе, например, через адресную строку веб-браузера или завиток, возвращает либо представление "текущего состояния", либо список ссылок с href для предшествующих состояний ресурса и/или способ запроса дискретных "событий", которые произошли с объектом.

Таким образом, если вы укажете "версия 1" объекта и затем воспроизведите каждое из событий против него, вы можете изменить его до "текущего состояния", и это событие может быть передано в клиент, который не хочет получать полные представления только потому, что одна небольшая часть сущности изменилась. Это в основном концепция "хранилища событий", которая покрыта множеством информации CQRS.

Что касается REST-совместимости, я считаю, что этот подход был выполнен (хотя я не уверен в потоковой стороне этого), я не могу вспомнить, было ли это в этой книге http://shop.oreilly.com/product/9780596805838.do (REST in Practice) или в презентации, которую я услышал Вон Вернон в этом записанном разговоре в QCon 2010: http://www.infoq.com/presentations/RESTful-SOA-DDD.

Он говорил о дизайне URI примерно так (я точно не помню)

host/entity < - текущая версия ресурса host/entity/events < - список событий, которые произошли с мутацией объекта в его текущее состояние

Пример:

host/entity/events/1 < - это будет соответствовать созданию объекта host/entity/events/2 < - это будет соответствовать второму событию, когда-либо имеющему объект

Возможно, у него также есть что-то для истории, полное состояние момента, например:

host/entity/version/2 < - это будет полное состояние объекта после события 2 выше.

Вон недавно опубликовал книгу "Внедрение Domain-Driven Design", которая из оглавления выглядит так: она охватывает REST и управляемую событиями архитектуру: http://www.amazon.com/gp/product/0321834577

Ответ 3

Я являюсь автором http://firehose.io/, основы реального времени, основанной на предпосылке, что Streaming RESTful API может и должен существовать. На веб-сайте проекта:

Firehose - это минимально инвазивный способ создания веб-приложений реального времени без сложных протоколов или переписывания приложения с нуля. Это грязный простой паб/субсервер, который поддерживает клиентские Javascript-модели в синхронизировать с кодом сервера через WebSockets или длительный опрос HTTP. Это полностью охватывает шаблоны проектирования RESTful, что означает, что вы в конечном итоге получите хороший API после создания вашего приложения.

Я надеюсь, что эта инфраструктура не позволит интернету вернуться в темные времена RPC, но мы увидим, что произойдет. Мы используем Firehose.io на производстве Опрос в любом месте, чтобы нажимать миллионы сообщений в день людям на разных устройствах. Он работает.