Является ли веб-связь в режиме реального времени несовместимой с парадигмой 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 на производстве Опрос в любом месте, чтобы нажимать миллионы сообщений в день людям на разных устройствах. Он работает.
