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

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

Tак там будет один URL (скорее всего просто в виде домена) даже для всех функций, не говоря уже о всех ресурсах. )))

_>>А далее, даже если мы возьмём MessagePack и HTTP/2 для REST, то это всё равно не позволит нам получить сравнимую эффективность из-за наличия в gRPC такого "типа данных" как stream. Который позволяет отправить множество сообщений в рамках одного запроса (а не проводить весь комплекс установки ip, tcp, http, ssl соединений для каждой маленькой пачки данных).
S>Не очень понятно, что нам помешает отправить в REST пачку данных в рамках одного запроса или реквеста.

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

S>Большинство REST-данных именно так и устроены. Более того — в RPC вы не сможете получить сравнимую с REST эффективность из-за отсутствия conditional get и delta encoding.

))) Обычно на эту тему рисуют такие картинки (кстати, там кажется тестировали даже на вашем родном .net'е) с разницей раз в 10:

	Диаграммка тестов

_>>Эээ что? )
S>Сказать серверу "данные вплоть до 18.02 у меня уже есть. Если есть что-то новее — то пришлите разницу. Если нет — то достаточно просто 304".

И что мешает сделать тоже самое с gRPC? )

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

Ну вот https://tinkoff.github.io/investAPI/ тебе реальный пример. )

S>>>То есть если нас устраивает ненадёжность — то без проблем, можно делать двусторонние каналы. А если нужна надёжность — то рисковать полагаться на клиента, который может лечь...
_>>Типа если клиент с REST ляжет, то это как-то поможет не забыть отреагировать в нужный момент на текущие данные? )))
S>Типа если REST-клиент ляжет, это никак не повлияет на поведение сервера. А ставить поведение всей системы в зависимость от того, смог ли клиент получить данные немедленно или нет — это путь к катастрофе.

Ну так а если это условие задачи (в биржевой торговле так и есть), то что тогда? )))

_>>Ну вот тебе простейшая (и опять же из вполне реальной практики) задачка. Есть шаговый манипулятор со свободным вращением (но без энкодера). И соответственно у управляющей им схемы есть две команды: move_left() и move_right(). Доступ к этому через RPC очевидно выглядит полностью естественно — прямо как и реальные команды. А вот как по твоему будет выглядеть логичный REST вариант интерфейса? )))
S>Погодите, у вас где-то за океаном стоит шаговый манипулятор, и вы хотите управлять им через RPC, я правильно понял?

Ну да)

S>И вас никак-никак не беспокоит то, что вы не имеете представления о его текущем положении?

Я же писал, что экондера нет. Да и не нужен он, т.к. на устройстве камера, поток от которой параллельно тоже идёт к пользователю (и тот глазами по картинке легко определяет нужное ему положение). Кстати, тут подумалось, что в рамках gRPC можно и поток данных от камеры сделать не параллельным где-то рядом, а прямо в рамках того же API (как stream кадров от сервера).

S>По-моему, эта схема архитектурно обречена. Чтобы спроектировать нормальное решение, надо начать плясать от задачи, а не от "у нас есть шаговый манипулятор, бутылка виски и два билета на бейсбол. Какой API нам выставить для всего этого?".

Я правильно понимаю, что данный поток слов надо воспринимать как слив по данному примеру? )))

_>>Ну возможно это мои личные субъективные ощущения (а индустрия возвращается к RPC по каким-то другим причинам), а возможно ты слепой (не видишь аргументов, а они есть). Не знаю.
S>Мне вот кажется, что индустрия просто так и не перешла на REST. Ну, то есть кто-то продолжал пилить RPC over HTTP, называя его REST — вот эти люди, понятное дело, с большим облегчением переезжают на всякие gRPC и MessagePack.

С учётом наличия такой https://github.com/grpc-ecosystem/grpc-gateway штуки, мне кажется что выбор о базовой реализации должен быть однозначным. ))) Хотя конечно же по настоящему модные возможности (типа двунаправленных потоков) там отсутствуют — ну это цена за желание поддержки легаси (REST).