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

как считаете, это костыль в API какой-то или какой-то правильный паттерн для обеспечения гарантии доставки и чего-нибудь еще?

я скорее про то, что это могло бы быть одним HTTP запросом

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

как считаете, это костыль в API какой-то или какой-то правильный паттерн для обеспечения гарантии доставки и чего-нибудь еще?

то есть, никаких весомых причин делать это на WS в два запроса туда-сюда - не было?

а чего у тебя, транзакция?

первый оповещает о наличии желающих воспользоваться сервисом, сервис может оптимизировать — например ожидаться пока наберется остаточное количество, прежде чем инстанс стартовать
второй запрос — давай, кидай
если глюсит, надо в API тайминги посмотреть, и в ответе на первый запрос, там может метка времени быть, через сколько можно второй раз сервис пиннуть

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

Могу судить тольк по своему проду. У нас запросы в ws делаются, толко для подписывание на что-то.
Что-то более сложное для простого сокета выглядит реально хрупки.

Ну да, но не особо дорогой. Wacom One Small вроде модель.

Айпадик нынче за 20к вроде можно взять новый? А вот карандашик уже под 8к?