Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sharov, Вы писали:
S>>Не очень я этот момент понимаю -- tcp тут и там, запрос\ответ тут и там. В чем разница тогда?
НС>Тут недавно был топик. Обсуждали API управления камерой. RPC style это методы Move, Rotate, Scale. REST style — методы PUT Position, PUT Angle, PUT Scale. Домашнее задание — какие будут эффекты от обрыва связи в первом и втором случае, как от них будем защищаться? Что произойдет если латентность соединения — единицы секунд? Что произойдет если понадобится доступ нескольких клиентов?
1)Что за обсуждение, можно ссыль?
2) С тз бэка едва ли будут различия кроме кодов возврата в случае rest. Т.е. какие могут быть различия, если одно можно выразить через другое, т.е.
rest код эмулировать с помощь rpc, а то и вовсе вызвать соотв. rpc метод, только вернуть соотв. http код? Эффекты от обрыва связи -- сделать повторный запрос с соотв. уникальным
ключем, либо идемпотентность. В чем проблема все это сделать и для rpc? Вот возьмем soap (http post), ну натянем на него семантику put и готово.
На счет латентности -- у нас tcp соединение в обоих случаях, поэтому будет долго идти ответ в обоих случаях.
Это если не касаться инф-ры, которая под http заточена -- кэширование, проксирование и т.п.
3)Вместо того, чтобы попытаться дать ответ на мой вопрос, завалили встречными вопросами да еще дз в придачу. Нехорошо-с.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Отличный пример, демонстрирующий разницу в REST и RPC подходах. S>>RPC прекрасно создается и на REST.
НС>gRPC ты хотел сказать? Иначе написанное тобой выглядит как бред.
Нет я про написанное тобой про RPC подходы.
gRPC работает по HTTP/2 навряд ли на камере есть настройка. S>> Не важно, как объектная модель использует транспорт.
НС>Именно это и важно если мы говорим о REST.
S>>А дальше REST, gRPC не суть.
НС>Еще как суть. А ты явно не понимаешь что такое REST и думаешь что это очередной RPC на базе JSON.
REST это HTTP/1 и набор правил. S>> REST это всего на всего набор правил для HTTP протокола
НС>Это набор архитектурных принципов. По твоей же ссылке: НС>
НС>REST (от англ. Representational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль...
И? То же самое можно передавать и по другим правилам, но использовать HTTP/2 и более расширенные возможности. S>>>>Там небось и поддержки HTTP/2 то нет. НС>>>Bullshit bingo! S>> Угу при этом для тех же IoT используются немного другие протоколы
НС>У тебя проблемы с пониманием написанного. REST это архитектурный стиль, а не протоколы.
Угу
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.
То есть нет официального стандарта, значит это архитектурный стиль!
Но использует он в основном HTTP/1 отсюда и ограничения и преимущества. S>> Тот же Swagger и OpenApi как раз и решают проблему OORPC
НС>Нет.
Аргументируй. По сути REST это некие правила поверх HTTP/1
То есть URL, Json сериализация, отсутствие состояния на сервере, кэширование, ну там еще балансировка, ну и еще мелочи и практически все! Все остальное это транспорт HTTP/1
gRPC тоже самое, только другая сериализация и транспорт HTTP/2
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
НС>>gRPC ты хотел сказать? Иначе написанное тобой выглядит как бред. S> Нет я про написанное тобой про RPC подходы.
Тогда ты написал бред.
S>gRPC работает по HTTP/2
gRPC работает по разным протоколам, в том числе по http 1.1
S> навряд ли на камере есть настройка.
НС>>Это набор архитектурных принципов. По твоей же ссылке: НС>>
НС>>REST (от англ. Representational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль...
S> И?
И все.
S> То же самое можно передавать и по другим правилам, но использовать HTTP/2 и более расширенные возможности.
Можно. И?
S> То есть нет официального стандарта,
Нету.
S> значит это архитектурный стиль!
Нет, не значит.
S>>> Тот же Swagger и OpenApi как раз и решают проблему OORPC НС>>Нет. S> Аргументируй.
Здравствуйте, Sharov, Вы писали:
S>1)Что за обсуждение, можно ссыль?
Лень искать, если честно. В этом же форуме где то было.
S>2) С тз бэка едва ли будут различия кроме кодов возврата в случае rest.
Нет, различия будут и существенные. Примерно такие же как между императивным и декларативным кодом. RPC это про actions, а REST это про state transfer.
S> Т.е. какие могут быть различия, если одно можно выразить через другое, т.е.
Архитектурные, и, как следствие, поведенческие.
S>rest код эмулировать с помощь rpc, а то и вовсе вызвать соотв. rpc метод, только вернуть соотв. http код?
То что одно можно эмулировать через другое не означает эквивалентности. Императивное программирование, к примеру, тоже можно сэмулировать в функциональном языке через монады. Но это не делает императивное программирование идентичным функциональному.
S>3)Вместо того, чтобы попытаться дать ответ на мой вопрос, завалили встречными вопросами да еще дз в придачу. Нехорошо-с.
Я тебе уже неоднократно говорил — ты слишком многого хочешь, как будто я тебе чем то обязан.
S>>2) С тз бэка едва ли будут различия кроме кодов возврата в случае rest. НС>Нет, различия будут и существенные. Примерно такие же как между императивным и декларативным кодом. RPC это про actions, а REST это про state transfer.
В чем проблема передавать состояние в rpc? В запросе идет объект с желаемым состоянием+id запроса.
S>> Т.е. какие могут быть различия, если одно можно выразить через другое, т.е. НС>Архитектурные, и, как следствие, поведенческие.
Пример можно? Как по разному будут обработаны обрывы свзяи, латентность?
S>>rest код эмулировать с помощь rpc, а то и вовсе вызвать соотв. rpc метод, только вернуть соотв. http код? НС>То что одно можно эмулировать через другое не означает эквивалентности. Императивное программирование, к примеру, тоже можно сэмулировать в функциональном языке через монады. Но это не делает императивное программирование идентичным функциональному.
Тут более конкретно -- один и тот же код может работать и там и там. В чем разница тогда?
S>>3)Вместо того, чтобы попытаться дать ответ на мой вопрос, завалили встречными вопросами да еще дз в придачу. Нехорошо-с. НС>Я тебе уже неоднократно говорил — ты слишком многого хочешь, как будто я тебе чем то обязан.
Ну это не я даю дз вместо ответа на простой вопрос.
Здравствуйте, Sharov, Вы писали:
S>>>2) С тз бэка едва ли будут различия кроме кодов возврата в случае rest. НС>>Нет, различия будут и существенные. Примерно такие же как между императивным и декларативным кодом. RPC это про actions, а REST это про state transfer. S>В чем проблема передавать состояние в rpc?
Тем что это будет уже не RPC.
S>>> Т.е. какие могут быть различия, если одно можно выразить через другое, т.е. НС>>Архитектурные, и, как следствие, поведенческие. S>Пример можно?
Пример уже был.
S>Как по разному будут обработаны обрывы свзяи, латентность?
Попробуй все же сам поразмышлять. Ты, к примеру, правильно вспомнил про идемпотентность. REST накладывает такие требования на ряд методов, а вот в RPC стиле никто этим, как правило, не заморачивается. В результате спрева плачем от сбоев, потом придумываем ретраи, потом внезапно оказывается что нужна идемпотентность и мы безим прикручивать велосипед. В то время как REST с самого неачала заставляет об этом думать.
Идея то очень простая. Когда проектировали HTTP, то по всем граблям уже прошли. Поэтому, когда ты проектируешь систему в рамках существующей идеологии, то ты эти грабли автоматично обходишь, да еще получаешь в довесок хорошую совместимость с существующей инфраструктурой. А когда начинаешь велосипеды изобретать, как нам тут бравый Сергинио советует, то готовь крепкий лоб.
НС>>То что одно можно эмулировать через другое не означает эквивалентности. Императивное программирование, к примеру, тоже можно сэмулировать в функциональном языке через монады. Но это не делает императивное программирование идентичным функциональному. S>Тут более конкретно
И там все так же конкретно. Ситуация ровно та же самая.
S> -- один и тот же код может работать и там и там. В чем разница тогда?
В чем разница между ФП и ИП? Ведь один и тот же ассемблерный код может работать и там и там.
S>Ну это не я даю дз вместо ответа на простой вопрос.
Простой? Это очень объемный вопрос. Краткий ответ я тебе дал. А копать за тебя — уж извини.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>gRPC ты хотел сказать? Иначе написанное тобой выглядит как бред. S>> Нет я про написанное тобой про RPC подходы.
НС>Тогда ты написал бред.
S>>gRPC работает по HTTP/2
НС>gRPC работает по разным протоколам, в том числе по http 1.1
Ну это для браузеров. gRPC-WEB https://habr.com/ru/company/microsoft/blog/487548/
Невозможно реализовать спецификацию gRPC HTTP/2 в браузере, потому что нет API браузера с достаточным детальным контролем над HTTP-запросами. gRPC-Web решает эту проблему будучи совместимым с HTTP/1.1 и HTTP/2.
gRPC-Web в ASP.NET Core или Envoy
Существует два способа добавления gRPC-Web в приложение ASP.NET Core.
Поддержка gRPC-Web вместе с gRPC HTTP/2 в ASP.NET Core. Этот параметр использует ПО промежуточного слоя, предоставленное пакетом Grpc.AspNetCore.Web.
Используйте поддержку gRPC-Web в прокси-сервере Envoy, чтобы транслировать gRPC-Web в gRPC HTTP/2. Затем переведенный вызов перенаправляется в приложение ASP.NET Core.
Есть свои плюсы и минусы этого подхода. Если среда приложения уже использует Envoy в качестве прокси-сервера, имеет смысл использовать Envoy и для предоставления поддержки gRPC-Web. Если требуется простое решение для gRPC-Web, для которого требуется только ASP.NET Core, используйте Grpc.AspNetCore.Web.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
НС>>gRPC работает по разным протоколам, в том числе по http 1.1 S> Ну это для браузеров.
Неважно. Важно что ты по прежнему не понимаешь разницу между архитектурными подходами и конкретными реализациями, у тебя в голове традиционно фантастическая каша из обрывков смыслов.
НС>Идея то очень простая. Когда проектировали HTTP, то по всем граблям уже прошли. Поэтому, когда ты проектируешь систему в рамках существующей идеологии, то ты эти грабли автоматично обходишь, да еще получаешь в довесок хорошую совместимость с существующей инфраструктурой. А когда начинаешь велосипеды изобретать, как нам тут бравый Сергинио советует, то готовь крепкий лоб.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>>Вообще то идемпотентность есть и настраивается
НС>Ничего не понял о чем ты и какое это имеет отношение к обсуждению.
О том, что как ты утвердаешь в gRPC нет idempotency
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
НС>>Ничего не понял о чем ты и какое это имеет отношение к обсуждению. S> О том, что как ты утвердаешь в gRPC нет idempotency
Ты совсем уже обнаглел? Это ты тут заявил, что там нет идемпотентности, да еще и спрашивал почему я фейспалмы рисую в ответ на подобное. А теперь заявляешь что это я подобную чушь утверждал.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Ничего не понял о чем ты и какое это имеет отношение к обсуждению. S>> О том, что как ты утвердаешь в gRPC нет idempotency
НС>Ты совсем уже обнаглел? Это ты тут заявил, что там нет идемпотентности, да еще и спрашивал почему я фейспалмы рисую в ответ на подобное. А теперь заявляешь что это я подобную чушь утверждал.
НС>>В чем тио больше, в чем то меньше
S>А в чем меньше?
В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?
То есть ты утверждал, что в gRPC меньше чем в REST. Или предполагал, что нужно строить велосипед?
На самом деле HTTP/2 тот же наследник HTTP/1 и там так же можно организовать кэширование
и солнце б утром не вставало, когда бы не было меня
Re[13]: язык (source of truth) будет язык схемы для этого JSON
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Да и сериализация в Json проигрывает тому же Protobuf
НС>Чем проигрывает? И какая связь protobuf с упомянутым чуть ранее xml?
В перформансе. С т.з. передачи данных, json, xml, protobuf, итд это сиблинги.
Re: Какой язык стоит выбрать для написания микросервисов
