Здравствуйте, alex_public, Вы писали:
_>И мой оппонент откровенно слился при решений этой простейшей задачки. Причём слился он очевидно потому, что у него REST головного мозга, а данная задача не очень канонично ложится на эту архитектуру. Но естественно он не мог этого признать и начал тупо вилять, рассказывая о том что надо просто взять другую железку и вот для неё то он уж напишет как надо...
Если хотите — да, я признаю, что в рамках задачи, где применить REST невозможно, невозможно применять REST и придётся жрать, что дают.

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

Если хотите, я приведу вам жизненные примеры.
Вот у меня много лет была сигнализация редкой модели томагавка — 9100. Её рукожопые авторы решили сделать управление в стиле RPC. У 9010 оно в стиле REST: запуск — одна кнопка, стоп — другая. Обе кнопки идемпотентны.
А у 9100 долгое нажатие на кнопку означает "запуск, если заглушен, или стоп, если запущен".
Вот я проклинал её тысячи раз. Сломал два брелка в приступе благодарности к авторам.
Потому, что при плохой связи (а она плохая более-менее всегда; обещанные 400м работают только в чистом поле без ЭМ-источников) эта штука упорно глючила. Плюс дребезг контактов, из-за которого выдержать нужные 3 секунды адски тяжело. В итоге простая вроде вещь занимала по несколько минут — то она потеряет сигнал "туда", и машина не заводится, то потеряет апдейт "обратно" — и я глушу заведённую машину.

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

Здравствуйте, alex_public, Вы писали:

_>Что-то ты бредишь или не знаю чем читал нашу беседу.

Думаешь, чем больше ты хамишь, тем более убедительным выглядишь?

_> Задача была сформулирована мною предельно просто

Задача твоя была призвана сменить тему. А когда тут никто на это не повелся — ты начал хамить.
Я тебе напомню с чего все началось:

Нюанс в том, что в данный момент основным подходом снова становится RPC.

А теперь поясни, как отличия между RPC и REST вылились в обязательную необходимость какого то аппаратного блока.
Это я уж не говорю о том, что сравнивать REST (идеологию) и gRPC(конкретный фреймворк) — не самое разумное занятие. Сравнивать можно либо HTTP+JSON с gRPC, либо REST с RPC.

_>: есть некая конкретная железка с конкретными "кнопками" и надо приделать (любым программным способом, без каких-либо ограничений на протокол) к ней удалённое управление (чтобы грубо говоря нажимать эти кнопки дистанционно).

Без промежуточного сервера на стороне железки? И этот момент ты, конечно, "забыл" уточнить в начале?

Еще раз, если ты с первого раза не понял:
1) Либо на стороне железки нет возможности выбирать протокол, и тогда пример нерелевантен топику от слова "совсем"
2) Либо протокол таки выбирать мы можем, и тогда твои рассказы про необходимость замены аппаратного блока и особенности разработки железок — грубая попытка подмены темы

Здравствуйте, Sinclair, Вы писали:

_>>И мой оппонент откровенно слился при решений этой простейшей задачки. Причём слился он очевидно потому, что у него REST головного мозга, а данная задача не очень канонично ложится на эту архитектуру. Но естественно он не мог этого признать и начал тупо вилять, рассказывая о том что надо просто взять другую железку и вот для неё то он уж напишет как надо...
S>Если хотите — да, я признаю, что в рамках задачи, где применить REST невозможно, невозможно применять REST и придётся жрать, что дают.

Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.

S>Но в рамках пользовательской задачи (а не ограничений, введённых безголовыми проектировщиками железки) REST как минимум не хуже RPC, а в ряде сценариев — лучше.

Ещё раз повторюсь, настоящий инженер должен уметь решать задачу в рамках данному ему ТЗ, а не вставать в позу, если ему не нравится доступное железо.

P.S. И кстати с учётом текущей геополитической обстановки, этот навык становится особо востребованным...

Здравствуйте, alex_public, Вы писали:

_>Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.
Это не REST, а RPC.
_>P.S. И кстати с учётом текущей геополитической обстановки, этот навык становится особо востребованным...
То есть вы думаете, что оптопары в РФ будут недоступны? Пессимистичненьно...

Здравствуйте, Ночной Смотрящий, Вы писали:

_>> Задача была сформулирована мною предельно просто
НС>Задача твоя была призвана сменить тему. А когда тут никто на это не повелся — ты начал хамить.

Нет, задачка была ответом на тезис собеседника о том, что CRUD (читай REST) подход идеален для абсолютно всех видов задач. Это был контрпример на такой тезис.

НС>Я тебе напомню с чего все началось:
НС>

НС>Нюанс в том, что в данный момент основным подходом снова становится RPC.

НС>А теперь поясни, как отличия между RPC и REST вылились в обязательную необходимость какого то аппаратного блока.

Чтобы понять это достаточно было прочитать нашу дискуссию, но ты конечно это не осилил, а влез так и не поняв о чём вообще речь.

НС>Это я уж не говорю о том, что сравнивать REST (идеологию) и gRPC(конкретный фреймворк) — не самое разумное занятие. Сравнивать можно либо HTTP+JSON с gRPC, либо REST с RPC.

gRPC — это конкретный фреймворк, который набирает в данное время большую популярность. Более того, у меня на глазах переписывают существующие REST (в классической реализации) интерфейсы на gRPC (в не REST стиле). Что является индикатором того, что мода на чистую REST архитектуру, доминировавшую одно время, проходит.

_>>: есть некая конкретная железка с конкретными "кнопками" и надо приделать (любым программным способом, без каких-либо ограничений на протокол) к ней удалённое управление (чтобы грубо говоря нажимать эти кнопки дистанционно).
НС>Без промежуточного сервера на стороне железки? И этот момент ты, конечно, "забыл" уточнить в начале?

Само собой сервер (ну если так можно назвать платку в несколько квадратных сантиметров) имеется. Без этого просто невозможно ничего сделать и озвучивать такое специально было бы просто смешно. И мой собеседник прекрасно это всё понял.

НС>Еще раз, если ты с первого раза не понял:
НС>1) Либо на стороне железки нет возможности выбирать протокол, и тогда пример нерелевантен топику от слова "совсем"
НС>2) Либо протокол таки выбирать мы можем, и тогда твои рассказы про необходимость замены аппаратного блока и особенности разработки железок — грубая попытка подмены темы

Протокол выбирать можно. А необходимость замены железа заявил как раз мой собеседник. Похоже ты тут демонстрируешь просто эталонный уровень "я не в теме". )))

Здравствуйте, Sinclair, Вы писали:

_>>Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.
S>Это не REST, а RPC.

Я знал (поэтому собственно и привёл этот пример изначально), что тебе это покажется не каноничным. ))) Но кстати интересно, какое из формальных требований REST ты видишь тут нарушенным (и чтобы при этом оно переставало быть нарушенном при наличие экодера)?

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

_>>P.S. И кстати с учётом текущей геополитической обстановки, этот навык становится особо востребованным...
S>То есть вы думаете, что оптопары в РФ будут недоступны? Пессимистичненьно...

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

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

Здравствуйте, alex_public, Вы писали:

_>Я знал (поэтому собственно и привёл этот пример изначально), что тебе это покажется не каноничным. ))) Но кстати интересно, какое из формальных требований REST ты видишь тут нарушенным (и чтобы при этом оно переставало быть нарушенном при наличие экодера)?
Representational State Transfer. Для REST главное — передача состояния, а не команд.

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


_>Да, и кстати оптопара не даст тебе возможность определения абсолютного положения. Только относительного (что глупо и не нужно, т.к. у тебя и так шаговый двигатель).
Она даст возможность инициализировать положение железки после включения локального контроллера (ну, или пропадания связи между железкой и контроллером, что с точки зрения архитектуры одно и то же)

Здравствуйте, alex_public, Вы писали:

_>Нет, задачка была ответом на тезис собеседника о том, что CRUD (читай REST) подход идеален для абсолютно всех видов задач.

Это где он такое написал?

НС>>А теперь поясни, как отличия между RPC и REST вылились в обязательную необходимость какого то аппаратного блока.
_>Чтобы понять это достаточно было прочитать нашу дискуссию, но ты конечно это не осилил,

Антон, судя по всему, тоже ее почему то не осилил. Их тут тысячи?

НС>>Это я уж не говорю о том, что сравнивать REST (идеологию) и gRPC(конкретный фреймворк) — не самое разумное занятие. Сравнивать можно либо HTTP+JSON с gRPC, либо REST с RPC.
_>gRPC — это конкретный фреймворк, который набирает в данное время большую популярность.

Ага, и при этом, как правильно заметил Cyberax, взрослые дядьки все равно проектируют для него API в REST стиле.

_> Более того, у меня на глазах переписывают существующие REST (в классической реализации) интерфейсы на gRPC (в не REST стиле). Что является индикатором того, что мода на чистую REST архитектуру, доминировавшую одно время, проходит.

Или индикатором того, что к вам пришел очередной архитект с NIH синдромом.

НС>>Без промежуточного сервера на стороне железки? И этот момент ты, конечно, "забыл" уточнить в начале?
_>Само собой сервер (ну если так можно назвать платку в несколько квадратных сантиметров) имеется. Без этого просто невозможно ничего сделать и озвучивать такое специально было бы просто смешно. И мой собеседник прекрасно это всё понял.

Ну то есть для замены RPC на REST никакого нового аппаратного блока все же не нужно.

_>Протокол выбирать можно. А необходимость замены железа заявил как раз мой собеседник.

Где он такое написал?

_>Похоже ты тут демонстрируешь просто эталонный уровень "я не в теме". )))

Ага, и Антон тоже не в теме. В теме только ты. О чем, собственно, я и написал в предыдущем сообщении.

Здравствуйте, alex_public, Вы писали:

_>Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.

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

Здравствуйте, Sinclair, Вы писали:

_>>Я знал (поэтому собственно и привёл этот пример изначально), что тебе это покажется не каноничным. ))) Но кстати интересно, какое из формальных требований REST ты видишь тут нарушенным (и чтобы при этом оно переставало быть нарушенном при наличие экодера)?
S>Representational State Transfer. Для REST главное — передача состояния, а не команд.

Да, это главное. Только надо понимать в каком смысле здесь говорится о передаче состояния. А именно, здесь подразумевается отказ от хранения состояния сервером — всё нужное приходит в запросе.

А если у нас такая задача, что в ней просто нет состояния в принципе?

Кстати, могу тебе ещё один вполне реальный пример привести. Серверу передаются некий скрипт, который он должен выполнить (и возможно прислать какие-то реакции, причём возможно не сразу, — зависит от самого скрипта). У меня вот тут под боком реально передвигается некая штука (и исполняет сложные команды)...

О, тут ещё подумалось... А ведь взаимодействие со всеми базами данных тоже же укладывается в этот сценарий (просто там в роли скрипта SQL и т.п. будут). Как насчёт показать преимущества REST в такой классической задаче? ))) В том смысле что реализовать не доступ к конкретной табличке (собственно это и есть функциональность 90% современных говносервисов в сети), а реализовать в стиле REST универсальный интерфейс доступа к БД, позволяющий выполнить произвольный SQL (для примера) запрос.

А то ты же говорил, что "Во всех случаях, АФАИР, RPC проиграл." и "В рамках CRUD можно представить всё, что угодно."...

_>>Да, и кстати оптопара не даст тебе возможность определения абсолютного положения. Только относительного (что глупо и не нужно, т.к. у тебя и так шаговый двигатель).
S>Она даст возможность инициализировать положение железки после включения локального контроллера (ну, или пропадания связи между железкой и контроллером, что с точки зрения архитектуры одно и то же)

И это будет абсолютно бесполезная и неудобная для пользователя функция. Потому что если ты будешь показывать ему это значение (а иначе зачем оно тогда?), то он привыкнет что грубо говоря 0 — это направление на север, а 180 — это на юг. А после следующего выключения энергии эти значения станут уже другими.

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

В общем похоже что гениальным архитекторам пока что ещё рано думать о железе...

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Почему невозможно то? Просто делаешь одну функцию Move (по методу POST) с одним булевым параметром (типа право/лево) и всё. Не вижу никаких проблем на самом деле.
НС>Тебе уже вопросы конкретные задали, но ты их поскипал. Что произойдет при обрыве соединения в момент посылки Move? Что произойдет если соединение оборвется в момент возврата отклика от сервера. Что будет если соединение с фиговой латентностью?
НС>А то что ты никаких проблем не видишь мы уже поняли.

Ты уже совсем заболтался что ли? ) У пользователя перед глазами видеопоток с камеры! И он отлично видит, встала она уже в нужную ему позицию или ещё нет. )))

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Нет, задачка была ответом на тезис собеседника о том, что CRUD (читай REST) подход идеален для абсолютно всех видов задач.
НС>Это где он такое написал?

Нет конечно. Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл.
В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.

Я же говорю, ты как обычно влезаешь, даже не поняв куда.

НС>>>Это я уж не говорю о том, что сравнивать REST (идеологию) и gRPC(конкретный фреймворк) — не самое разумное занятие. Сравнивать можно либо HTTP+JSON с gRPC, либо REST с RPC.
_>>gRPC — это конкретный фреймворк, который набирает в данное время большую популярность.
НС>Ага, и при этом, как правильно заметил Cyberax, взрослые дядьки все равно проектируют для него API в REST стиле.

Т.к. REST — это по сути подмножество RPC, то очевидно что вполне естественная возможность. Правда в тех gRPC интерфейсах, что видел я, чаще всего применялся тип stream, что очевидно является уже выходом из REST подмножества.

_>>Протокол выбирать можно. А необходимость замены железа заявил как раз мой собеседник.
НС>Где он такое написал?

_>Архитектуру можешь плодить какую хочешь. Но ты уже показал, что в рамках REST подхода ты можешь только слиться с невнятными оправданиями.
Почему же? я прикручу к этой железке датчик нуля, сделаю процедуру инициализации, и выставлю REST-протокол по управлению положением.

_>>Похоже ты тут демонстрируешь просто эталонный уровень "я не в теме". )))
НС>Ага, и Антон тоже не в теме. В теме только ты. О чем, собственно, я и написал в предыдущем сообщении.

Не, он то как раз полностью адекватно общается и всё понимает. А вот ты очевидно влез не читая.

Здравствуйте, Sinclair, Вы писали:

О, я тут заметил что как-то пропустил твоё старое сообщение (я вообще через уведомления в почте читаю этот форум). Ну сейчас отвечу тогда...

_>>Вот зачем писать такой длинный текст, чтобы продемонстрировать подобную глупость? То, что ты описал — это даже не близко двухсторонний канал. Двухсторонний, это когда в рамках одного соединения и клиент и сервер могут в любой момент (в том числе даже и совпадающие) инициировать отсылку сообщения на противоположную сторону.
S>Ну, и в чём подвох?

Подвох в том, что ни в каких текущих реализациях REST это невозможно. Собственно поэтому grpc-gateway не является полноценным, а может эмулировать только подмножество возможностей grpc.

_>>Осталось теперь только понять зачем может понадобится подобное в биржевом API. )))
S>Точно так же, как и в любом другом — если мне нужен список текущих цен, то мне выгоден любой способ сокращения трафика — в частности, если меняются не все цены, то получение дельты экономит трафик.

Чтобы у тебя возникла экономия трафика с твоим подходом, тебе надо будет сделать как минимум два последовательных вызова этой функции. А это значит, что ты уже не правильно пользуешься этим API, т.к. для таких задач существует поток от сервера.

_>>Или быть может ты хочешь тут высказать идею о том, что непрерывный опрос в цикле — это лучше, чем ожидание сообщения об изменение с сервера? )))
S>Расскажите же мне, как ожидание сообщения будет работать после обрыва канала и восстановления подключения?

Восстанавливаешь соединение и снова подписываешься на нужные данные.

_>>Вот, ты кажется уже начинаешь понимать как оно должно быть (в тинькоф api как раз подписка реализована, но подписка на поток от сервера!). Теперь ещё возможно дойдёшь до того, что непрерывный опрос в цикле — это очевидное зло и нагрузка впустую, и тогда сумеешь описать нормальную систему (выкинув REST), как раз как у тинькова.
S>Всё зависит от типа задачи. REST дружелюбен к любой топологии — в частности, я могу реализовать ресурс "история изменений", который будет бесконечным. Как число Pi.
S>Как мы уже обсудили выше, COMET никуда не делся. Более того — в отличие от gRPC, после обрыва я могу запросить историю изменений с того места, до которого я дочитал в прошлый раз.

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

_>>А теперь попробуй реализовать обратное. Т.е. создать произвольный gRPC API с помощью REST.
S>А в чём проблема? Просто берём и заворачиваем всё, что угодно, в POST.

Ну вот заверни двухсторонний поток в POST. )))

_>>У тебя какое-то представление о современных сетях из прошлого века. У меня даже из дома пинг до тинькова 2 мс (и то это округление скорее всего).
S>Просто вам повезло с домом. У меня — 44мс. Физику не обманешь, и если у вас сервер расположен в 20000км от клиента, то нулевым пинг вы не сделаете никак.

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

_>>У gRPC со всем этим получше будет. )))
S> Рассскажите, что делать при обрыве соединения, передающего stream?

Переподключаешься и запрашиваешь stream снова. А в чём проблема то?

_>>Задача звучит так: есть готовая железка и ты должен запрограммировать для неё удалённый доступ. Ты уже продемонстрировал, что не смог справиться с этой задачей.
S> Хорошо, что мне обычно ставят задачи вроде "увеличить продажи в таком-то сегменте в такое-то количество раз" или "сократить количество обращений в службу поддержки в месяц на единицу продаж".

Что-то не похоже на техническую должность, скорее на менеджерскую... )

_>> Такие системы (управления) всегда монопользовательские!
S>Как вы собираетесь это обеспечить?

Логин и пароль естественно. Ты вообще что ли никогда не встречался с камерами наблюдения? ))) Сейчас же это уже вообще бытовое устройство по сути, которое многие дома ставят. Ещё за животными подглядывают с работы... )))

Здравствуйте, alex_public, Вы писали:
_>Да, это главное. Только надо понимать в каком смысле здесь говорится о передаче состояния.
В прямом.
_>А именно, здесь подразумевается отказ от хранения состояния сервером — всё нужное приходит в запросе.
Нет конечно, это чушь. Именно что понимается хранение состояния сервером.
_>А если у нас такая задача, что в ней просто нет состояния в принципе?
Тогда можно обойтись без REST. Но даже в таких задачах бывают неожиданные полезности от REST.
_>Кстати, могу тебе ещё один вполне реальный пример привести. Серверу передаются некий скрипт, который он должен выполнить (и возможно прислать какие-то реакции, причём возможно не сразу, — зависит от самого скрипта). У меня вот тут под боком реально передвигается некая штука (и исполняет сложные команды)...
Да, это один из канонических примеров преимуществ REST.
Потому, что REST позволяет, к примеру, убедиться, что скрипт выполнится не более 1 раза, даже если коммуникационный канал между клиентом и сервером сбоит.
REST позволит нам от задачи "мы что-то там отправили на сервер, хз чо получилось и получилось ли вообще" перейти к задаче "управляем очередью заданий на сервере" — в том числе видеть, исполнился ли скрипт, или ещё ждёт в очереди, или он исполняется.
Будет возможность прервать или отменить исполнение скрипта.

_>О, тут ещё подумалось... А ведь взаимодействие со всеми базами данных тоже же укладывается в этот сценарий (просто там в роли скрипта SQL и т.п. будут). Как насчёт показать преимущества REST в такой классической задаче? )))
Да, SQL — это классика REST.
_>В том смысле что реализовать не доступ к конкретной табличке (собственно это и есть функциональность 90% современных говносервисов в сети), а реализовать в стиле REST универсальный интерфейс доступа к БД, позволяющий выполнить произвольный SQL (для примера) запрос.
В мире SQL REST-стиль — это отказ от хранимых процедур в пользу View + Instead-of triggers.
Я этот пример студентам рассказываю

_>А то ты же говорил, что "Во всех случаях, АФАИР, RPC проиграл." и "В рамках CRUD можно представить всё, что угодно."...
А то.

_>И это будет абсолютно бесполезная и неудобная для пользователя функция. Потому что если ты будешь показывать ему это значение (а иначе зачем оно тогда?), то он привыкнет что грубо говоря 0 — это направление на север, а 180 — это на юг. А после следующего выключения энергии эти значения станут уже другими.
Смотрите, как это работает. К камере крепится диск с 1 отверстием, разделяющий светодиод и фотодиод. Оптопара монтируется в выбранном нами направлении — например, север.
Всякий раз, как "сервер" просыпается, он начинает крутить камерой по часовой стрелке, пока оптопара не покажет "есть!". Теперь мы знаем состояние камеры — она смотрит на север.
Когда мне приходит команда "повернись в направлении 276", сервер выдаёт моторчику заданное количество шагов. Ну там — 0, если камера уже смотрит на 276, и 36, если камера смотрит на 240. При этом он, понятное дело, изменяет состояние некоторого внутреннего "регистра" — глобальной переменной, которая описывает текущее состояние камеры.

_>В общем похоже что гениальным архитекторам пока что ещё рано думать о железе...
%)

Здравствуйте, alex_public, Вы писали:

_>Подвох в том, что ни в каких текущих реализациях REST это невозможно.
Хм. Я вроде описал способ, которым это делается.

_>Восстанавливаешь соединение и снова подписываешься на нужные данные.
Падажжите. Ну так в моей подписке был провал неизвестной длительности.

_>Ты похоже чего-то не понимаешь))) Те данные, что присылаются потоком — они потом нигде не хранятся, ни в каких историях.
Вы так говорите, как будто это хорошо.
_>В истории бирж хранятся свечи, с максимальным разрешением по времени в 1 минуту. А поток присылает изменения цены в реальном времени (может быть секундные, а может быть часовые — зависит от ситуации и инструмента).
Что такое "часовые изменения в реальном времени"?

_>Ну вот заверни двухсторонний поток в POST. )))
Я продолжаю непонимать в чём проблема.

_>Однако ты легко можешь взять сервер в любом датацентре Москвы и получишь результат как у меня. И для этого вовсе не надо залезать в датацентр Тинькова.
Ок, давайте так — сколько наносекунд занимает разбор "текстовых хидеров" в REST-запросе, который лишний по сравнению с gRPC?

_>Переподключаешься и запрашиваешь stream снова. А в чём проблема то?
В том, что кусок стрима прощёлкан клювом.

_>Что-то не похоже на техническую должность, скорее на менеджерскую... )


_>Логин и пароль естественно. Ты вообще что ли никогда не встречался с камерами наблюдения? ))) Сейчас же это уже вообще бытовое устройство по сути, которое многие дома ставят. Ещё за животными подглядывают с работы... )))

Ну вот, я взял и зашёл на эту камеру с телефона, и одновременно с компьютера.
Я кручу на телефоне "вправо", а жена в это время крутит "влево". Что будет происходить?

Однопользовательскость не определяется логином и паролем.

Здравствуйте, Sinclair, Вы писали:

_>>А именно, здесь подразумевается отказ от хранения состояния сервером — всё нужное приходит в запросе.
S>Нет конечно, это чушь. Именно что понимается хранение состояния сервером.

Какая милота. Кстати, не напомнишь, как там звучит 2-ой пункт из требований REST? )))

_>>А если у нас такая задача, что в ней просто нет состояния в принципе?
S>Тогда можно обойтись без REST. Но даже в таких задачах бывают неожиданные полезности от REST.

По правильному тут надо читать не "можно обойтись без REST", а "лучше обходиться без REST". )))

_>>Кстати, могу тебе ещё один вполне реальный пример привести. Серверу передаются некий скрипт, который он должен выполнить (и возможно прислать какие-то реакции, причём возможно не сразу, — зависит от самого скрипта). У меня вот тут под боком реально передвигается некая штука (и исполняет сложные команды)...
S>Да, это один из канонических примеров преимуществ REST.
S>Потому, что REST позволяет, к примеру, убедиться, что скрипт выполнится не более 1 раза, даже если коммуникационный канал между клиентом и сервером сбоит.
S>REST позволит нам от задачи "мы что-то там отправили на сервер, хз чо получилось и получилось ли вообще" перейти к задаче "управляем очередью заданий на сервере" — в том числе видеть, исполнился ли скрипт, или ещё ждёт в очереди, или он исполняется.
S>Будет возможность прервать или отменить исполнение скрипта.

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

_>>О, тут ещё подумалось... А ведь взаимодействие со всеми базами данных тоже же укладывается в этот сценарий (просто там в роли скрипта SQL и т.п. будут). Как насчёт показать преимущества REST в такой классической задаче? )))
S>Да, SQL — это классика REST.

О, даже так...

Т.е. я правильно понимаю, что скажем эта https://www.postgresql.org/docs/current/protocol.html штука является классикой REST? )

_>>В том смысле что реализовать не доступ к конкретной табличке (собственно это и есть функциональность 90% современных говносервисов в сети), а реализовать в стиле REST универсальный интерфейс доступа к БД, позволяющий выполнить произвольный SQL (для примера) запрос.
S>В мире SQL REST-стиль — это отказ от хранимых процедур в пользу View + Instead-of triggers.
S>Я этот пример студентам рассказываю

Так ты интерфейс то опиши... Вот у нас у клиента есть произвольная SQL (+DML+DDL, ну как обычно) строка. Куда её сунуть и как получить результат исполнения в REST стиле...

_>>И это будет абсолютно бесполезная и неудобная для пользователя функция. Потому что если ты будешь показывать ему это значение (а иначе зачем оно тогда?), то он привыкнет что грубо говоря 0 — это направление на север, а 180 — это на юг. А после следующего выключения энергии эти значения станут уже другими.
S>Смотрите, как это работает. К камере крепится диск с 1 отверстием, разделяющий светодиод и фотодиод. Оптопара монтируется в выбранном нами направлении — например, север.
S>Всякий раз, как "сервер" просыпается, он начинает крутить камерой по часовой стрелке, пока оптопара не покажет "есть!". Теперь мы знаем состояние камеры — она смотрит на север.
S>Когда мне приходит команда "повернись в направлении 276", сервер выдаёт моторчику заданное количество шагов. Ну там — 0, если камера уже смотрит на 276, и 36, если камера смотрит на 240. При этом он, понятное дело, изменяет состояние некоторого внутреннего "регистра" — глобальной переменной, которая описывает текущее состояние камеры.

Ха, ты имел ввиду оптопару в таком смысле. Понятно) Просто традиционно её применяют совсем по другому (по сути для подсчёта шагов). А то, что описал ты традиционно называется совсем по другому: концевики. И они бывают и оптические и механические и магнитные. Да, и кстати никакой диск при их использование (оптических естественно) не нужен (а вот для подсчёта шагов как раз используется диск со множеством прорезей).

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

Здравствуйте, alex_public, Вы писали:

S>>Нет конечно, это чушь. Именно что понимается хранение состояния сервером.
_>Какая милота. Кстати, не напомнишь, как там звучит 2-ой пункт из требований REST? )))
Вы явно чего-то фундаментального не понимаете про REST. Из того, что RESTful протокол занимается передачей состояния, вовсе не означает, что "всё состояние передаётся в запросе".
Например, когда я пытаюсь выполнить регистрацию на рейс, состояние всех регистраций хранится на сервере.

_>По правильному тут надо читать не "можно обойтись без REST", а "лучше обходиться без REST". )))
Прежде чем давать советы, как и что правильно читать, неплохо было бы разобраться с основами REST.
Ну, возьмём например такой сервис, у которого вообще нет никакого состояния.
Ему на вход подаётся, допустим, небольшая картинка. Скажем, 200*80px. Сервер ставит на неё свой водяной знак.
Можно это трактовать как RPC: "Вот тебе картинка, нарисуй на ней".
А можно — как REST: "Отдай мне картинку с такими параметрами".
Второй подход выигрывает тем, что можно снизить нагрузку от повторных обращений, просто выставив хидер Expiration: Never.

Можно реализовать сервис, который отдаёт десятичные знаки числа Pi. Он тоже полностью stateless.
REST-подход означает, что мы легко привинчиваем к нему Range хидер: сервис просто пропускает сколько-то первых цифр, которые уже есть у клиента, и экономит ему трафик.

_>Как забавно. ) Так что же тебе помешало тогда в предыдущей задачке (которая очевидно является подмножеством этой) применить тот же подход? ) Ну типа очередь заданий виде "поворот налево" и "поворот направо"? )))
А там примерно так и будет; потому что поворот камеры осуществляется не мгновенно. Поэтому когда делается PUT или PATCH, придётся отвечать 202.

_>Т.е. я правильно понимаю, что скажем эта https://www.postgresql.org/docs/current/protocol.html штука является классикой REST? )
Нет. Сам по себе DML является практически классикой REST, потому что как раз и описывает CRUD операции.

_>Так ты интерфейс то опиши... Вот у нас у клиента есть произвольная SQL (+DML+DDL, ну как обычно) строка. Куда её сунуть и как получить результат исполнения в REST стиле...
Вот вы опять подменяете задачу конкретным решением.
Задача у вас в чём? Управлять состоянием БД.
Ну вот был у нас такой доисторический stateful протокол. Разработанный для текстовых терминалов, перед которыми будет сидеть живой пользователь, и набирать все вот эти вот begin transaction.
Если мы поставим такую же задачу перед современным архитектором, то получится протокол ODATA

_>Ну и да, такое будет работать. Но это, как я и говорил изначально, будет дополнительный аппаратный блок и дополнительная прошивка. А с изначальной задачей на заданном железе ты справиться не смог.
Прошивка чего? Там всей доп. стоимости на десять центов.
А вы попробуйте справиться с задачей "написать бота, который склеивает панораму из снимков каждый час, и потом монтирует из этого фильм в mp4".

Здравствуйте, Sinclair, Вы писали:

_>>Подвох в том, что ни в каких текущих реализациях REST это невозможно.
S>Хм. Я вроде описал способ, которым это делается.

Ну что за детских сад? Вот давай ты попробуешь реализовать в стиле REST например тот же самый потоковый протокол Тинькова информации с биржи. Т.е. вот мы подключаемся; подписываемся на информацию о 5 акциях; нам идёт в ответ непрерывный поток этой информации; далее в какой-то момент мы хотим ещё и о какой-то 6-ой акции получать информацию и изменяем свою подписку; и после этого получаем уже поток с информацией о 6 акциях. И всё это конечно в рамках одного соединения. Ну и как ты это сделаешь?

_>>Восстанавливаешь соединение и снова подписываешься на нужные данные.
S>Падажжите. Ну так в моей подписке был провал неизвестной длительности.

И? Эти данные уже давно стухли.

_>>В истории бирж хранятся свечи, с максимальным разрешением по времени в 1 минуту. А поток присылает изменения цены в реальном времени (может быть секундные, а может быть часовые — зависит от ситуации и инструмента).
S>Что такое "часовые изменения в реальном времени"?

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

_>>Однако ты легко можешь взять сервер в любом датацентре Москвы и получишь результат как у меня. И для этого вовсе не надо залезать в датацентр Тинькова.
S>Ок, давайте так — сколько наносекунд занимает разбор "текстовых хидеров" в REST-запросе, который лишний по сравнению с gRPC?

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

_>>Переподключаешься и запрашиваешь stream снова. А в чём проблема то?
S>В том, что кусок стрима прощёлкан клювом.

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

_>>Логин и пароль естественно. Ты вообще что ли никогда не встречался с камерами наблюдения? ))) Сейчас же это уже вообще бытовое устройство по сути, которое многие дома ставят. Ещё за животными подглядывают с работы... )))
S>
S>Ну вот, я взял и зашёл на эту камеру с телефона, и одновременно с компьютера.
S>Я кручу на телефоне "вправо", а жена в это время крутит "влево". Что будет происходить?
S>Однопользовательскость не определяется логином и паролем.

И снова детский сад? Вот как будто бы ты не знаешь как решается данный вопрос. Что есть две стандартные стратегии: или текущее соединение блокирует все новые или же любое новое соединение выкидывает предыдущее. И в разных задачах используется или один или второй подход.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Sinclair, Вы писали:

_>>>Подвох в том, что ни в каких текущих реализациях REST это невозможно.
S>>Хм. Я вроде описал способ, которым это делается.

_>Ну что за детских сад? Вот давай ты попробуешь реализовать в стиле REST например тот же самый потоковый протокол Тинькова информации с биржи. Т.е. вот мы подключаемся; подписываемся на информацию о 5 акциях; нам идёт в ответ непрерывный поток этой информации; далее в какой-то момент мы хотим ещё и о какой-то 6-ой акции получать информацию и изменяем свою подписку; и после этого получаем уже поток с информацией о 6 акциях. И всё это конечно в рамках одного соединения. Ну и как ты это сделаешь?
Сделаю POST, в тело которого запишу список 5 акций. Для простоты — в line-delimited JSON. В ответ нам начинает ехать поток обновлений в какой-то кодировке.
Для простоты — line-delimited JSON.
Поток никогда не закрывается. Ни туда, ни обратно. Всё.
Тут, конечно, нарушены некоторые принципы REST, но в целом всё работает
Более того — я ж не обязан делать именно так. Я вполне могу отправить и фиксированный список акций, просто получив в ответ бесконечный поток.

_>>>Восстанавливаешь соединение и снова подписываешься на нужные данные.
S>>Падажжите. Ну так в моей подписке был провал неизвестной длительности.

_>И? Эти данные уже давно стухли.
Ну как это "стухли"?
Вот у меня есть 500 инструментов. Обновляются по разному. Кто-то раз в час, кто-то раз в секунду. Связь на 10 секунд пропала. Мне теперь надо перевычитать цены для всех 500? Изменилось-то за это время может быть 40 позиций. Опять же — как мне убедиться, что между моментами "я прочитал все цены" и "я начал ловить поток изменений" не было потерянных изменений?

_>Так я вроде приводил графики (причём даже не свои, а какие-то дотнетные), но ты сказал что нарисовать всё что угодно можно...
Это потому, что непонятно, какая задача решалась. Я вот показываю примеры, в которых при неустойчивой связи RPC будет гораздо хуже по трафику, чем REST.

_>Так он же стухла уже. ))) Как весь предыдущий стрим собственно — важно только текущее значение и всё.
А что такое "текущее значение"? Вот у меня была последняя цена инструмента 99.40. Он обновляется редко. Я заново подписался на поток, десять минут жду — нету изменений. Какую цену мне предполагать? 99.40? А может там как раз изменение пролетало, пока я моргнул?

_>И снова детский сад? Вот как будто бы ты не знаешь как решается данный вопрос. Что есть две стандартные стратегии: или текущее соединение блокирует все новые или же любое новое соединение выкидывает предыдущее. И в разных задачах используется или один или второй подход.
Здорово. То есть теперь мы не можем посмотреть одну и ту же камеру с двух компьютеров.
Смотрите, как быстро вы закапываете свой продукт Меня всегда изумляли ситуации, когда люди намеренно делают продукт хуже, вместо того, чтобы немножко подумать.
Ну, как сони, у которой половина продуктов не могут одновременно заряжаться и работать

Здравствуйте, Sinclair, Вы писали:

_>>Какая милота. Кстати, не напомнишь, как там звучит 2-ой пункт из требований REST? )))
S>Вы явно чего-то фундаментального не понимаете про REST. Из того, что RESTful протокол занимается передачей состояния, вовсе не означает, что "всё состояние передаётся в запросе".

Так ты не ответил, какой там 2-ой пункт из требований REST? И как это пересекается с твоим пониманием REST "Именно что понимается хранение состояния сервером"? )))

_>>По правильному тут надо читать не "можно обойтись без REST", а "лучше обходиться без REST". )))
S>Прежде чем давать советы, как и что правильно читать, неплохо было бы разобраться с основами REST.
S>Ну, возьмём например такой сервис, у которого вообще нет никакого состояния.
S>Ему на вход подаётся, допустим, небольшая картинка. Скажем, 200*80px. Сервер ставит на неё свой водяной знак.
S>Можно это трактовать как RPC: "Вот тебе картинка, нарисуй на ней".
S>А можно — как REST: "Отдай мне картинку с такими параметрами".
S>Второй подход выигрывает тем, что можно снизить нагрузку от повторных обращений, просто выставив хидер Expiration: Never.

Прикинул вероятность побитового совпадения двух произвольных цветных картинок размером 200*80px и в очередной раз оценил твоё умение проектировать системы. )

S>Можно реализовать сервис, который отдаёт десятичные знаки числа Pi. Он тоже полностью stateless.
S>REST-подход означает, что мы легко привинчиваем к нему Range хидер: сервис просто пропускает сколько-то первых цифр, которые уже есть у клиента, и экономит ему трафик.

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

_>>Как забавно. ) Так что же тебе помешало тогда в предыдущей задачке (которая очевидно является подмножеством этой) применить тот же подход? ) Ну типа очередь заданий виде "поворот налево" и "поворот направо"? )))
S>А там примерно так и будет; потому что поворот камеры осуществляется не мгновенно. Поэтому когда делается PUT или PATCH, придётся отвечать 202.

О, т.е. теперь уже оказывается, что можно решить задачку на REST и без дополнительного железа? Или что? )))

_>>Т.е. я правильно понимаю, что скажем эта https://www.postgresql.org/docs/current/protocol.html штука является классикой REST? )
S>Нет. Сам по себе DML является практически классикой REST, потому что как раз и описывает CRUD операции.

Не слышал про такой протокол, как DML... К какой СУБД он даёт сетевой доступ и по какому порту обычно? )

_>>Так ты интерфейс то опиши... Вот у нас у клиента есть произвольная SQL (+DML+DDL, ну как обычно) строка. Куда её сунуть и как получить результат исполнения в REST стиле...
S>Вот вы опять подменяете задачу конкретным решением.
S>Задача у вас в чём? Управлять состоянием БД.
S>Ну вот был у нас такой доисторический stateful протокол. Разработанный для текстовых терминалов, перед которыми будет сидеть живой пользователь, и набирать все вот эти вот begin transaction.

Я правильно понял, что теперь у нас и SQL плохой и устаревший? )))

S>Если мы поставим такую же задачу перед современным архитектором, то получится протокол ODATA

Я правильно понял, что этот мертворождённый уродец, является твоим идеалом? )