Каковы подводные камни использования Websockets вместо RESTful HTTP?

В настоящее время я работаю над проектом, который требует, чтобы клиент запрашивал большую работу и отправлял ее на сервер. Затем сервер делит работу и отвечает массивом URL-адресов для клиента, чтобы сделать GET-вызов и передать данные обратно. Я - greenhorn в проекте, и в настоящее время я использую Spring websockets для повышения эффективности. Вместо того, чтобы клиенты постоянно пинговали сервер, чтобы увидеть, есть ли у него результаты, готовые к обратному потоку, websocket теперь просто напрямую свяжется с клиентом hooray!

Было бы плохо, если бы websockets управляли всем процессом из конца в конец? Я использую STOMP с веб-сайтами Spring, будут ли еще проблемы с канавкой REST?

ОТВЕТЫ

Ответ 1

С RESTful HTTP у вас есть система запроса/ответа без учета состояния, где клиент отправляет запрос, а сервер возвращает ответ.

С помощью webSockets у вас есть система с поддержкой состояния (или потенциально с точки зрения состояния), в которой сообщения могут отправляться в любом случае, и отправка любого заданного сообщения ниже накладных расходов, чем с помощью запроса/ответа HTTP RESTful.

Эти два являются довольно разными структурами с различными сильными сторонами.

Основные преимущества подключенного webSocket:

  • Двусторонняя связь. Таким образом, сервер может в любое время уведомить клиента о чем-либо. Таким образом, вместо опроса сервера на некоторый регулярный интервал, чтобы узнать, есть ли что-то новое, клиент может установить webSocket и просто прослушать любые сообщения, поступающие с сервера. С точки зрения сервера, когда возникает событие, представляющее интерес для клиента, сервер просто отправляет сообщение клиенту. Сервер не может сделать это с помощью простого HTTP.

  • Уменьшить накладные расходы для каждого сообщения. Если вы ожидаете большого количества трафика, протекающего между клиентом и сервером, тогда есть более низкие накладные расходы на сообщение с помощью webSocket. Это связано с тем, что TCP-соединение уже установлено, и вам просто нужно отправить сообщение в уже открытый сокет. С помощью запроса HTTP REST вам необходимо сначала установить TCP-соединение, которое несколько раз в промежутке между клиентом и сервером. Затем вы отправляете HTTP-запрос, получаете ответ и закрываете TCP-соединение. HTTP-запрос обязательно будет включать некоторые служебные данные, такие как все файлы cookie, которые выровнены с этим сервером, даже если они не имеют отношения к конкретному запросу. HTTP/2 (новейшая спецификация HTTP) допускает некоторую дополнительную эффективность в этом отношении, если он используется как клиентом, так и сервером, потому что одно TCP-соединение может использоваться не только для одного запроса/ответа. Если вы начертили все запросы/ответы, происходящие на уровне TCP, чтобы сделать запрос/ответ https REST, вы наверняка заметите, сколько стоит, просто отправляя сообщение по уже установленному webSocket.

  • Более высокая шкала в некоторых случаях.. При меньших накладных расходах на сообщение и отсутствии опроса клиентов, чтобы узнать, что-то новое, это может привести к добавленной масштабируемости (большее количество клиентов на данном сервере может служить). Есть и недостатки в масштабируемости webSocket (см. Ниже).

  • Состоятельные подключения. Не применяя файлы cookie и идентификаторы сеансов, вы можете напрямую сохранить состояние в своей программе для данного соединения. Несмотря на то, что большая часть разработок была выполнена с использованием соединений без состояния, чтобы решить большинство проблем, иногда это просто проще при связях с состоянием.

Основные преимущества HTTP-запроса/ответа RESTful:

  • Универсальная поддержка. Трудно получить более универсальную поддержку, чем HTTP. В то время как webSockets пользуются относительно хорошей поддержкой сейчас, все еще есть некоторые обстоятельства, при которых поддержка webSocket не доступна регулярно.

  • Совместимость с другими серверными средами. Есть серверные среды, которые не позволяют длительным серверам (в некоторых ситуациях с общим хостингом). Эти среды могут поддерживать HTTP-запрос, но не могут поддерживать длительные соединения webSocket.

  • Более высокая шкала в некоторых случаях. Требование webSocket для непрерывно подключенного сокета TCP добавляет новые требования к масштабируемости для инфраструктуры сервера, которые запросы HTTP не требуют. Таким образом, это становится компромиссным пространством. Если преимущества веб-сокетов на самом деле не нужны или используются значительным образом, то HTTP-запросы могут действительно лучше масштабироваться. Это определенно зависит от конкретного профиля использования.

  • Для одноразового запроса/ответа один HTTP-запрос более эффективен, чем создание webSocket, используя его, а затем закрывая его. Это связано с тем, что открытие webSocket начинается с HTTP-запроса/ответа, а затем после того, как обе стороны согласились перейти на подключение к webSocket, можно отправить фактическое сообщение в WebSocket.

  • Безстоящий. Если ваша работа не осложняется наличием безгражданности, тогда мир без гражданства может значительно упростить масштабирование (просто добавьте больше серверных процессов за балансировщик нагрузки).

  • Автоматически кэшируемый. При правильных настройках сервера HTTP-ответы могут быть кэшированы браузером или прокси-серверами. Не существует такого встроенного механизма для запросов, отправленных через webSockets.

Итак, чтобы решить, как вы задали вопрос:

Каковы подводные камни использования веб-сайтов вместо RESTful HTTP?

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

  • Все возможные клиенты или наборы инструментов не поддерживают веб-узлы или запросы, сделанные над ними, на тот же уровень, что и HTTP-запросы.

  • Некоторые из менее дорогостоящих серверных сред не поддерживают длительные серверные процессы, необходимые для поддержки веб-сокетов.

Если важно, чтобы ваше приложение получало уведомления о ходе работы с клиентом, вы можете использовать длительное http-соединение с продолжающимся прогрессом, отправленным вниз, или вы можете использовать webSocket. WebSocket, вероятно, проще. Если вам действительно нужен только WebSocket для относительно короткой продолжительности этого конкретного действия, то вы можете найти лучший общий набор компромиссов, используя webSocket только в течение времени, когда вам нужна возможность нажимать данные клиенту и затем используя HTTP-запросы для обычных действий запроса/ответа.

Ответ 2

Это действительно зависит от ваших требований. Службы REST могут быть намного прозрачнее и проще для разработчиков разработчиком по сравнению с Websockets.

Используя Websockets, вы удаляете большинство преимуществ, которые предлагает веб-сервис RESTful, например возможность ссылки на ресурс через URI. На самом деле вы должны выяснить, какие преимущества имеют REST и гипермедиа, и на основе этого решают, важны ли эти преимущества для вас.

Конечно, вполне возможно создать веб-сервис RESTful и увеличить его с помощью API на основе websocket для ответов в реальном времени.

Но если вы создаете сервис, который вы собираетесь использовать только в контролируемой среде, единственным недостатком может быть то, что не каждый клиент поддерживает веб-порты, в то время как практически любой тип среды может выполнять простой HTTP-вызов.