RESTful HTTP и веб-сокет в одном приложении?

Если приложение уже открыто WebSocketдля прямых трансляций, должен ли я использовать его AJAXдля других коммуникаций с сервером?

Поскольку соединение уже открыто, мы должны использовать его для запросов, которые Request/Responseне являются в реальном времени?

Я предпочитаю RESTful HTTPзапросы, потому что нахожу их легче отлаживать. Вы можете использовать браузер с URL или curl, чтобы проверить, что возвращает API. Вам не нужно писать код, чтобы открыть WebSocket.

Было бы странно иметь RESTful HTTP APIи WebSocketв одном приложении?

rest ajax websockets

— Марк
источник

«вам не нужно писать какой-либо код для тестирования API» Не могли бы вы объяснить это немного подробнее? Что заставляет вас думать, что вам не нужно тестировать API?

— Элиас Ван Отегем

Инструменты разработчика Chrome, если я не ошибаюсь, позволяют открывать веб-сокет и отправлять сообщения в режиме реального времени

— maple_shaft

@EliasVanOotegem Хороший вопрос. Извините, это не было ясно. Вам все еще нужно протестировать API с модульным проектом на стороне сервера. Я имею в виду, что если вы хотите быстро взглянуть на то, что будет возвращать API, вы можете использовать указатель с URL. Вам не нужно писать код, чтобы открыть веб-сокет. Я обновил свой вопрос.

— Марк

@maple_shaft Это хорошо, но вы должны быть на странице с открытым WebSocket на сервере.

— Marc

Одна из основных целей разработки Websockets заключается в том, что он позволяет передавать протоколы HTTP и Websocket через один и тот же порт. Это достигается за счет явного требования клиента выполнить рукопожатие Websocket с запросом на обновление HTTP. Таким образом, сервер может обрабатывать стандартное соединение HTTP-запроса, а также запрос HTTP Upgrade, который теперь обновляется до постоянного двунаправленного дуплексного соединения.

Так что да, это, безусловно, допустимый вариант использования, однако, СЛЕДУЕТ ли вам делать это для своего конкретного приложения, это совсем другой вопрос. Веб-сокеты полезны и имеют смысл, когда у вас есть сценарии, когда сервер должен иметь возможность отправлять незапрошенные данные клиенту (прямые каналы). Протокол HTTP и службы REST полезны, когда вы хотите заблокировать синхронный запрос данных клиентом.

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

— maple_shaft
источник

Это то, что мне было интересно. Имеет смысл использовать веб-сокеты для прямой трансляции в реальном времени, но как быть с операциями CRUD? По моему мнению, для них имеет смысл использовать стандартный HTTP-запрос.

— Marc

@Marc, я не нахожу странным разделять операции CRUD и задачи в реальном времени (одна использует HTTP, а другая - веб-сокеты) ... но ... я верю, что вы получите лучшую скорость отклика от сервера, а также лучшая производительность, если вы используете постоянное соединение (Websocket) для всех ваших операций. Это действительно зависит от ваших потребностей в CRUD, но я бы не стал уклоняться от интерфейса CRUD Websocket.

— Мист

upvoted! новичок здесь, так как вы упомянули, что оба должны передаваться через один и тот же порт, если вы выбираете, скажем, цены на акции из живого потока и из-за большого трафика трафик отключается на несколько минут, как бы вы получили данные между ними или что существуют стратегии для решения этой проблемы

— PirateApp