Реализация API на вебсокетах

Использование WebSocket API в веб-приложении: https://netbeans.org/kb/docs/javaee/maven-websocketapi_ru.html

November 29, 2012

Для работы с API я предлагаю использовать JSON RPC поверх вебсокетов. Зачем так делать? - Это экономия ресурсов сервера, причем нехилая ...

Глубокое заблуждение человека, наблюдающего за всем с колокольни frontend-а. Дело в том, что требования к ресурсам сервера, по большому счету, пропорциональны количеству одновременно поддерживаемых соединений. Для работы со stateless API как раз более экономным является использование HTTP.

Кроме того, есть еще соображения простоты программирования и надёжности работы серверной части, что тоже входит в конфликт с предложением. Тут для каждой конкретной задачи нужен свой подход.

Для клиента 2/3 времени от выполнения запроса уходит на установку соединения с сервером.

Давно уже есть такая штука как HTTP/2 - это когда пачка HTTP-запросов передается по одному TCP-соединению. Ну а держать соединение, когда запросы закончились - это слишком большая роскошь.

Еще недостаток REST (RESTful) - это то что данные предлагается получать методом GET

А кто вас заставляет использовать именно REST? :) К примеру, вы можете проектировать API на одних POST-запросах - никто вам не запрещает. Частенько так и делается - разумными людьми. У меня такое впечатление, что если хотя бы один из сотни сможет ответить на вопрос, для чего может потребоваться именно REST (а не просто HTTP), то это будет очень хорошо ). В основном все просто тупо действуют по шаблону.

Я сейчас занимаюсь только тем что штампую SPA. Так вот у меня все равно уведомления через веб сокеты работают. Зачем мне сранный REST?

Ну, скажем, уведомления вы делаете через веб-сокеты, скорее всего, не от хорошей жизни, а просто потому что push-уведомления еще не везде работают как надо. Через годик-другой ситуация изменится. Именно для уведомлений веб-сокеты как раз абсолютно не нужны, а для мобильных устройств даже вредны.

Вообще, веб-сокеты и постоянные TCP-соединения - это для вполне конкретного класса задач (онлайн-игр, чатов и пр).

У нас

Вас там много?

Это твой пыхтон пыхтит как умеет. Возьми нормальный сервер.

Для работы с API я предлагаю использовать JSON RPC поверх вебсокетов.

Выкинь это

JSON RPC

дерьмо:

Причин много. Основные - отсутствие валидации, слабая система типов, текстовое тормазное(и избыточное) говно.

Возьми хотя-бы тот же protobuf. Хотя он то ещё дерьмецо, но из готового особо ничего и нет. Хотя я не знаю что там происходит с твоим пхп.

Еще недостаток REST (RESTful) - это то что данные предлагается получать методом GET, а он неможет иметь тела, поэтому приходится параметры из QueryString цеплять, приводить к нужным типам (некоторые драйверы баз данных типа того же asyncpg не приводят автоматически строки к нужным типам).

Рест и хттп вообще - это всё лютое дерьмо. И сомневаюсь, что кто-то в здравом уме будет его использовать по собственной воле.

Таким образом выигрывают клиент и сервер.

Да.

Я сейчас занимаюсь только тем что штампую SPA. Так вот у меня все равно уведомления через веб сокеты работают. Зачем мне сранный REST?

Незачем. Всё правильно делаешь. Только выкинь json-rpc, если конечно у тебя там не жабаскрипт/пхп на обоих концах. Да даже если он - лучше выкинуть.

Судя по тому что graphql ты не упомянул - не искал.

Эти глупые попытки тулить базворды, которые вчера услышал за партой. gql никоим образом не является альтернативой rpс.

Описал ли ты необходимость использовать RESTful, когда данные можно и POST-запросами получать ? Нет, не описал

Кому и зачем нужна эта необходимость? Мне она не нужна, а то, что нужно тебе - меня мало волнует.

Неа, пользователь даже не заметит разницы.

Ты бы хоть в школу начальную сходил, там тебя научат считать. Человек замечает лаги даже в 20-30мс, когда как та же нотификация через хттп-дристню требует х2 по летенси сети, а это уже куда больше 20-30мс. Реальная пинга до конечного юзера в среднем находится в пределах 50-100мс. Меньше 50 - это редкость. Очевидно, что при прочих равных нотификация через хттп-дристню будет тормозней, причём заметно.

Опять же, там уже ламерок обделался, но поведаю тебе причину. хттп-дристня не можешь осуществлять запросы между запросом и ответом, поэтому все эти потуги про keep-alive полная херня. Это работает только для последовательной цепочки запросов.

В рамках же реального мира, никому эта последовательная параша не нужна и коммуникация должна производится и производится. Поэтому летенси сети будет проявляться не только при нотификации. Ты будешь либо ждать ответа на прошлый запрос, либо создавать новый - со всеми вытекающими последствиями по летенси.

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

Мне она не нужна, а то, что нужно тебе - меня мало волнует.

что ты, черт возьми, несешь

Ты вещал про какую-то необходимость, которая существует только в твоих фантазиях. Я ни про какую необходимость не знаю и знать не должен, зачем ты к ней, т.е. к своим фантазиям, апеллируешь?

Опять же, что за глупые потуги отвечать выборочно?

Типичный линуксохипстер, который матчасти не знает и уже распустив сопли истошно орёт про что-то сраное и не нужное.

Я вещал ? Что ? ты несешь какую-то чушь, очевидно я спрашивал почему у ТС свет клином сошелся на RESTful и почему бы не получать данные с помощью POST. А ты, видимо летаешь в своем мире и интерпретируешь как хочешь

Балаболка, не играй со мною в игры - всё равно всё для тебя закончится плачевно.

По поводу твоим последующих рассуждений, ТС тебе вещает о рест как о некой базовой сущности веба. Свет клином сошёлся на нём не у ТС"а, а у веба в целом. Это первое.

Второе, с каких пор ты вообще сравниваешь некие паттерны организации апи(как минимум) и какой-то неведомый пост? Ты хочешь предложить ему рест на пост? Нет. Дак зачем ты сравниваешь жопу и палец?

Опять же, твои потуги вообще не имеют смысла, т.к. ущербность передачи аргументов через url это лишь один из критериев ущербности хттп-дристни определённых автором. Зачем ты выдрал кусок и начал что-то вещать - мне не ясно.

В целом это типично для трепла. Выдрал из моего ответа кусок и ответил. Выдрал из поста автора кусок и ответил. Только эти ответы не имеют смысла.

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

о рест как о некой базовой сущности веба.
Свет клином сошёлся на нём не у ТС"а, а у веба в целом

что за чушь. То что ты или он читал только о РЕСТ, это не значит что только им пользуются.

неведомый пост

Вполне себе ведомый, вон даже ТС жалуется что GET-ом не удобно данные собирать, больше тело задавать сложно, так пускай собирает POST-ом, никто не заставляет придерживаться концепции которая не подходит к ситуации.

для трепла.

а это уже смешно и иронично

json rpc потому как браузерный яваскрипт нативно может сериализовать/десериализовать объекты. в яваскрипт вообще большая беда при работе с бинарными данными. в ноде придумали Buffer, а в браузер ничего кроме типизированных массивов. с другой стороны они нам особо и не нужны (бинарные данные можно передавать в base64). строки, числа, булевы без проблем передать можно. эти типы есть в любом языке. пхп я не пользуюсь давно. на нем в принципе невозможно задуманное сделать. питон либо нода. мне по душе больше питон.

UPD: я посмотрел гугловую библиотеку и стороннюю. гугловой я сразу говорю «НЕТ». мне не нравится что она тянет дохуя кала с собой, так еще она оказалась очень медленной.

про ограничение в 2000 символов на длинну request uri я не упоминал. в это ограничение я еще никогда не упирался.

(больше похож на чей-то фейк, но это мы опустим)

Да это же очевидный царь.

Это последнее что я напишу, ты очевидный неадекват который еще и не знает о чем пишет.

Ты почто с Царём споришь, холоп?

Вообщем, хочу услышать мнения.

Я одобряю, пили.
Только соединением надо что-то делать, когда оно реально не нужно (юзер уснул за компом) или рвётся.

Хоть было адресовано и не мне, но тоже попробую ответить по поводу:

ТС тебе вещает о рест как о некой базовой сущности веба. Свет клином сошёлся на нём не у ТС"а, а у веба в целом.

Ну не надо так всех в одну кучу... ). И не надо путать с «вебом в целом» определенную группу недостаточно компетентных, в основном, начинающих веб-программистов, которых как научили в ВУЗе, что надо делать REST, так они «прыгают за бананом», абсолютно не понимая, когда это действительно нужно использовать, а когда можно и без этого обойтись.

Нет никакой базовой сущности веба под названием «REST» - если она и существует, то только в вашей с TC-ом голове. Ну и некоторых других - тех, кто не сможет даже толком объяснить, в каких конкретно случаях следует применять REST-шаблон и почему.

И нет никакого особого повода отказываться от старого доброго HTTP и нового HTTP/2 и уползать без особой надобности на супер-новые варианты. Вот HTTP - это действительно базовая сущность веб-а ) Кстати, HTTP/2 в отличии от «keep-alive» уважается всеми веб-обозревателями - API-шные запросы и статика бегают именно по одному TCP-шному соединению.

Вообще, для начала нужно хорошенько ознакомиться с WebSocket-протоколом, почитать более подробно о том, как организуется WebSocket-соединение и какие при этом происходят обмены между клиентом и веб-сервером. Сразу станет ясно, что WebSocket - это не способ супер-ускорения типичной серии API-шных запросов. Одна полумегабайтная картинка на главной странице сайта отправит в урну всю вашу «экономию» )

Ну а как кодировать данные внутри запросов - это дело десятое. Нравится JSON-RPC - на здоровье. Ну и WebSocket-ами никто, естественно, не запрещает пользоваться - только не надо возводить их в какой-то абсолют. Всё должно использоваться по делу и осмысленно - там, где это действительно дает выгоду во всех отношениях.

superhackprokiller1997@gmail.com

Дальше не читал 🤣

Вообще, надо чётко различать два случая: 1) случай stateless API и 2) прикладной протокол взаимодействия между клиентом и сервером, подразумевающий наличие определенного состояния в силу специфики конкретного приложения. Если говорить конкретно о вебе (а не просто об Интернете), то 1-й случай — это наиболее типичный вариант обмена данными между веб-клиентом и веб-сервером. Соответственно, превносить лишние усложнения в этот типичный вариант — не очень хорошая идея. Ну а использование WebSocket-ов — это достаточно сильное усложнение, поскольку требует закрепления на сервере за каждым WebSocket-ом отдельного, пускай и зеленого thread-а или использования в backend-части асинхронного стиля программирования. Стоит ли всё это городить просто ради того, чтобы чуток сэкономить траффик на HTTP-заголовках... ?

Вот представьте себе сайт с очень большой аудиторией, но где каждый посетитель заглядывает разок в день на пару страниц. Ну и на хрена вам здесь WebSocket — чтобы ресурсы держать лишнее время за уже неактивными посетителями?

Ну не надо так всех в одну кучу... ). И не надо путать с «вебом в целом» определенную группу недостаточно компетентных, в основном, начинающих веб-программистов, которых как научили в ВУЗе, что надо делать REST, так они «прыгают за бананом», абсолютно не понимая, когда это действительно нужно использовать, а когда можно и без этого обойтись.

Прохладные истории. Только вот есть реальный мир, в котором всё население состоит из тех, кто по твоему мнению не такие. И да, где-то есть кто-то вменяемый, но мы обсуждаем мейнстримные реалии.

Ну и некоторых других - тех, кто не сможет даже толком объяснить, в каких конкретно случаях следует применять REST-шаблон и почему.

Какие у тебя странные представления о реальности. У 95% нет никакого выбора и нет никаких ответов. Он делают так как научили, как сказали. Все эти рассуждения о том, что существуют какие-то случаи, выбор и прочие стори - это стори и не более. Реальность она другая.

И нет никакого особого повода отказываться от старого доброго HTTP и нового HTTP/2 и уползать без особой надобности на супер-новые варианты.

Ну вот, пошли глупые оправдания. Мало того, что ты уже признал поражение, когда начал кидаться базвордами. http/2 не имеет никакого отношения к хттп - его назвали так лишь потому, чтобы у тебя не порвало шаблон. И меня удивляет, что ты не понимаешь даже таких базовых вещей.

Хттп2 - мусорный костыльный, который хоть и не хттп, но пытается мимикрировать в рамках хттп-реалий. А хттп-реалии мусор сами по себе.

Как я уже говорил, это «новы варианты», существовали тогда, когда адепты хттп под стол пешком ходили.

Вообще, для начала нужно хорошенько ознакомиться с WebSocket-протоколом, почитать более подробно о том, как организуется WebSocket-соединение и какие при этом происходят обмены между клиентом и веб-сервером. Сразу станет ясно, что WebSocket - это не способ супер-ускорения типичной серии API-шных запросов. Одна полумегабайтная картинка на главной странице сайта отправит в урну всю вашу «экономию» )

В твоих фантазиях она что-то куда-то отправит. Опять же, что именно и с чем мне нужно ознакомится? Очевидно, что тебе никто не выдавал ВС за что-то идеальное. Это единственное, что есть и что позволяет реализовать вменяемый подход.

Опять же, какие-то фантазии вместо аргументации. Зачем ты дёргаешь какие-то левые фразы и тезисы, про то же какое-то ускорение. Ускорение - это лишь одним из критериев, которых не один десяток.

Для меня основным критерием является то, что организация нормального обмена данными, мало того, что надёждней, эффективней, мощней - она попросту нативней, проще и логичней, чем твоя мусорная отрыжка каких-то дегроидов.

У хттп-дристни нет ни единого преимущества, кроме того, что ламерки не осилят и «так принято».

Ну а как кодировать данные внутри запросов - это дело десятое. Нравится JSON-RPC - на здоровье. Ну и WebSocket-ами никто, естественно, не запрещает пользоваться - только не надо возводить их в какой-то абсолют. Всё должно использоваться по делу и осмысленно - там, где это действительно дает выгоду во всех отношениях.

Абсолютно мусорные тезисы. Никаких «по делу нет», ни у кого хттп и прочего мусора никаких дел нет. ВС - является абсолютом в рамках того, что есть. И никакая бездарная отрыжка ему не ровня.

Очевидно, что ты будешь сколь угодно мазаться, ретранслируя мне дефолтные агитки «у всего есть назначение», «каждой задаче» и прочая херня. Только вот это всё ламерские фантазии и не более того, а мотивация у вас одно - оправдать свой выбор без выбора. Ведь ты не жрёшь дерьмо - ты сделал осознанный выбор. Верю.

И правильно. Сначала взять попкорн или заварить чая.

Да этого 🐓 сразу в игнор. Че я шизоидов с досок не видал.
Но обострение перед 1 сентября это забавно.

Че я шизоидов с досок не видал.

Ну, не знаю. Я тоже разных видел, но чтобы Царя. (Хотя я видел одного, который затмил бы трёх Царей, но тут его быстро бы утопили).

Но обострение перед 1 сентября это забавно.

Да он работает уже где-то походу.

Да полно их было в программачах, и 10 лет назад. Лиспошизики, борщехлебы и прочие интересные(нет) личности.
Вначале интересно зоонаблюдать, но они быстро сдуваются и просто шитпостят.

Прохладные истории. Только вот есть реальный мир, в котором всё население состоит из тех, кто по твоему мнению не такие. И да, где-то есть кто-то вменяемый, но мы обсуждаем мейнстримные реалии.
...
Какие у тебя странные представления о реальности. У 95% нет никакого выбора и нет никаких ответов. Он делают так как научили, как сказали. Все эти рассуждения о том, что существуют какие-то случаи, выбор и прочие стори - это стори и не более. Реальность она другая.

Ну так если этому «населению» втюрить в мозги очередную догму (типа, WebSocket - это круто, а остальное - г...), они также начнут применять всё это абсолютно бездумно и будет от этого только один вред :)

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

Но есть и куча людей, которые всего этого не понимают и даже не пытаются понять. У них только куча понтов и очень мало реальных знаний, которыми следует оперировать для принятия правильных, оптимальных решений. Ну так это не «мейнстрим» - это просто люди, которые занимаются не своим делом.

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

в яваскрипт вообще большая беда при работе с бинарными данными. в ноде придумали Buffer, а в браузер ничего кроме типизированных массивов
ничего кроме типизированных массивов

Что несешь, поехавший? Buffer был введен в ноду до введения в стандарт типизированных массивов. Сейчас Buffer в ноде это и есть типизированный массив Uint8Array.

...с методами как у строки (indexOf, например). в браузере и такого нет. совсем не понял твоего вскукарека: я не писал, что буфера нодовские раньше появились типизированных массивов. ты чет сам придумал, сам типа опроверг.

Ты написал чушь. Я тебе объясняю, что нодовский буфер - это и есть типиированный массив, такой же как в браузере. Это обертка блядь, над типизированным массивом.

с методами как у строки (indexOf, например). в браузере и такого нет

Тебя научить программировать и расширять классы? Ты совсем дурак?

это ты дурак. в божественном питоне встроенные бинарные строки. не хочу я писать аналог нодовского буффера для браузера. мне он не нужен. от того что Buffer наследуется от FastBuffer, а тот в свою очередь от Uint8Array, мне ни тепло, ни холодно. чего ты хочешь мне не понятно.

все равно уведомления через веб сокеты работают. Зачем мне сранный REST?

С этого можно было начинать. Незачем.

А вообще, если уйти чуть-чуть в абстракции и дилетантскую терминологию - если у тебя рест активно дудосит сервак, то какой смысл в нём? Явно для сокета задача.

ну он хоть и толстит, но на самом деле все по делу пишет

Нет, на самом деле он просто пишет несвязный бред. Как и обычно.

Connection: Keep-Alive уже советовали?

Кому оно нужно, когда есть эталонная Царская реализация на вебсокетах.

Человек замечает лаги даже в 20-30мс

Откуда инфа? Вроде биологическое ограничение это 80мс

Connection: Keep-Alive уже советовали?

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

Если законфигурить на сервере использование HTTP/2, тогда действительно весь траффик гонится по одному TCP-соединению, но возникает интересная побочка - когда на странице много картинок (в том числе тех, которые подгружаются про запас - на случай скроллирования), то чисто визуально отображение страницы начинает «тормозить». Начальная статика начинает в реальном времени грузиться медленнее, поскольку гонится по TCP-соединению отдельными фрагментами, чередующимися с ответами на другие HTTP-запросы. Нагрузка на сервер уменьшается - но комфортность просмотра на стороне посетителя сайта падает :)

Так что, при включении HTTP/2 его нужно конфигурить и ограничивать режим мультиплексирования соединения - так, чтобы число параллельно обслуживаемых HTTP-запросов не превышало какого-то разумного порога.

Для работы с API я предлагаю использовать JSON RPC поверх вебсокетов. Зачем так делать? - ...

Если слегка подытожить...

Вообще говоря, тезис о том, что одно TCP-соединение лучше и быстрее нескольких, срабатывает не всегда - это зависит от того, какие-данные, какого объема и как часто реально гоняются по соединению. Гляньте хотя бы предыдущее замечание насчет HTTP/2.

Использовать REST-подход, как уже было сказано выше, никто не заставляет — это актуально, только если для проекта существенна возможность промежуточного кэширования HTTP-ответов сторонними сервисами. Для обычных сайтов (особенно для SPA), это не так уж и важно — можете использовать те HTTP-методы, какие вам удобны. Не мешайте в одну кучу REST и HTTP - в принципе, всё API можно сделать на одной URL-ке и POST-запросах.

Что касается полного перевода API c HTTP на WebSocket, то тут, увы, есть одна заковыка, которая сразу ограничивает область применимости вашего подхода - это SEO. Если вы собираетесь «штамповать SPA сайты», то вы должны знать, как в настоящее время реально обеспечивается индексирование SPA-сайтов в основных поисковых системах. Так что, таким образом можно более-менее спокойно поступить только с той частью API, которая не имеет отношения к формированию индексируемого контента. Всё остальное надо изначально увязывать с поддержкой SEO.

Вот как-то так...

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

Несколько AJAX-запросов? Вряд ли. Ну и в любом случае если браузер лучше знает, как грузить быстрей, зачем ты его хочешь замедлить?

когда на странице много картинок (в том числе тех, которые подгружаются про запас - на случай скроллирования), то чисто визуально отображение страницы начинает «тормозить»

На мой взгляд эту проблему лучше решать на самой странице. Например эти картинки про запас показывать только когда страница полностью загружена, чтобы они не мешали основному контенту (JavaScript-ом или может в HTML есть какие-нибудь атрибуты).

С вебсокетами тяжело работать, они могут не пройти через прокси (HTTP вообще запросто, HTTPS через MITM тоже могут не пролезть). Но в теории, конечно, можно и на вебсокетах, просто придётся наворотить кучу кода для надёжной работы.

С вебсокетами тяжело работать, они могут не пройти через прокси (HTTP вообще запросто, HTTPS через MITM тоже могут не пролезть).

Ну так это наоборот хорошо, лол.

Вообщем, хочу услышать мнения.

Идея хорошая, но реализация у тебя - говно.

Где валидация, где секурити, как узнать кто из клиентов пнул запрос, как отключить сессию, где пингалка чтобы следить за отпавшими запросами, где возможность фалбачнуться на хттп? Где в конце концов возможность сгенерить жс клиента для апи чтобы не писать все запросы руками?

ЗЫ: У меня в проде жсон рпц через вебсокеты живет.

жсон рпц через вебсокеты

Дистанционное махание кадилом через вебсокеты? ☺

Несколько AJAX-запросов? Вряд ли.

Если ты сразу запускаешь несколько AJAX-запросов (вешаешь их на промисы), то они реально гонятся через разные TCP-соединения наряду со статикой. Это можно наблюдать в веб-обозревателе в окне средств разработчика. У каждого веб-обозревателя есть какой-то внутренний или настраиваемый лимит на максимальное число таких соединений.

Ну и в любом случае если браузер лучше знает, как грузить быстрей, зачем ты его хочешь замедлить?

А как я его хочу замедлить? Я вроде ничего такого не предлагал - я наоборот за гибкий подход: выбирать подходящее решение исходя из конкретики. Хотя, что касается API, то тут как раз не надо оставлять это дело полностью на усмотрение веб-обозревателя.

Что касается HTTP/2, то я просто упомянул про это, поскольку в теме поднят вопрос упаковки нескольких запросов в одно TCP-шное соединение.

На мой взгляд эту проблему лучше решать на самой странице. Например эти картинки про запас показывать только когда страница полностью загружена

Ну, в общем-то да. Только это не всегда изначально очевидно и требует дополнительных программистских усилий, которых программеры норовят избежать )

Нет, у них не настолько длинные руки.

Хорошо, когда твой сайт не работает у части клиентов? Предлагаю кардинальное решение: вообще не делать сайт. Будет ещё лучше.

Всё так, но зачем себя загонять в рамки RPC и тем более REST?

Прелесть вебсокетов в их асинхронности. Почему не строить API поверх концепции асинхронных сообщений?

rpc более мощная концепция, нежели мусорные сообщения. rpc итак асинхронный, а так же, как более мощная(общая) концепция, очевидно, что она может представлять в себе примитивную херню вида «сообщения».

rpc итак асинхронный

фейспалм.жпг