Если ваша служба websocket всегда обрабатывает каждое соединение одинаково, тогда нет необходимости требовать строку пути или строку запроса в URI. (Ну, технически у вас должна быть строка пути, но каждый раз это может быть только один символ '/'.)
Однако, если ваша служба websocket хочет иметь возможность предоставлять разный контент для разных клиентов, то использование строки пути в URI может быть удобным способом для клиентов указать, какой тип контента им интересен. Возможно, ваша служба чата предлагает чаты для нескольких разных тем, и в этом случае вы можете решить попросите клиента использовать строку пути, чтобы указать желаемый topi c. Что-то вроде ws://localhost:8080/sport
, ws://localhost:8080/politics
или ws://localhost:8080/cooking
, или вы можете пойти дальше и иметь ws://localhost:8080/sport/football
, ws://localhost:8080/sport/golf
и ws://localhost:8080/sport/tennis
и т. Д.
Запрос -URI "метода GET [RFC2616] используется для идентификации конечной точки соединения WebSocket, чтобы оба домена могли обслуживаться с одного IP-адреса ...
Это просто обычный виртуальный хостинг. Веб-сервер, работающий с одним IP-адресом, может поддерживать несколько веб-сайтов на основе host
части URI.
... и позволять нескольким конечным точкам WebSocket обслуживаться одним сервером.
Каждый из приведенных мной примеров путей идентифицирует отдельную независимую конечную точку, обслуживаемую одним вашим сервером websocket.
В этом конкретном примере конечная точка веб-сокета представляет собой своего рода чат, но в более общем плане конечная точка веб-сокета связана с каким-либо потоком данных, часто с односторонним каналом (веб-сокет может предлагать поток текущего цены на акции для некоторой коллекции акций, указанной в строке запроса URI), но потенциально двунаправленный канал и потенциально интерактивный птичий канал (например, ваш чат).