Re[20]: язык (source of truth) будет язык схемы для этого JS
От: Ночной Смотрящий Россия  
Дата: 26.06.22 10:22
Оценка:
Здравствуйте, Serginio1, Вы писали:

НС>>Ну и что? Почему это плохо?

S> Да потому, что JS ограничен!

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

НС>>Проблема в том, что натягивание системы типов статического языка на сети аналогично натягиванию той же системы типов на РСУБД. Если язык специально под это не подгонять выходит какашка. С сетями та же история. Либо протокол уродский, либо систему типов, описывающих сетевое API приходится сильно урезать.

S> C# прекрасно натягивается.

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

НС>>А замапить JSON на сложные типы в 2022 году совершенно не проблема.

S> Ну вот сам JSON анахронизм для 2022 года.

Bullshit bingo! Опять пустые лозунги.

НС>>При чем тут многопоточность?

S> Ну при том, что в браузере нет многопоточности

Какое это имеет отношение к API для сети?

S>и не используется двухканальный режим чтения и записи


Может потому что дуплекс фигово работает в глобальных сетях? Да не, не может быть

S>>> Ну есть gRPC и в конце концов можно gRPC-Web или сервер микс gRPC c Json

НС>>И нафига?
S>Для таких как ты,

О, перешел на личности. Со сливом.

НС>>В чем тио больше, в чем то меньше

S>А в чем меньше?

В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?

НС>>SOAP похоронил сам себя, ибо идея OORPC нежизнеспособна. Либо получается неудобное, ненадежное и тормозное чудовище, либо SOAP урезается до крайне примитивных протоколов.

S>А gRPC это не OORPC?

Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[21]: язык (source of truth) будет язык схемы для этого JS
От: rudzuk  
Дата: 26.06.22 12:40
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

НС> В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?


Время идет, мантры все те же... Да с этим вашим "работающим" из коробки кешированием уже все говна наелись, наелись настолько, что впендюривают в урл рандом, доп. параметром.
avalon/3.0.0
Re[21]: язык (source of truth) будет язык схемы для этого JS
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.06.22 15:35
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Serginio1, Вы писали:


НС>>>Ну и что? Почему это плохо?

S>> Да потому, что JS ограничен!

НС>Теперь попробуй доказать что унаследованные от него ограничения критичны для коммуникаций.

https://russianblogs.com/article/2086122683/

HTTP / 2 не определяет JavaScript API и не поможет вам с легкостью создать REST API. В настоящее время клиенты JavaScript, работающие в веб-браузерах, имеют ограниченное использование новых функций. Однако для обмена данными между серверами HTTP / 2 предоставляет множество способов выйти за рамки существующих API REST.


НС>>>Проблема в том, что натягивание системы типов статического языка на сети аналогично натягиванию той же системы типов на РСУБД. Если язык специально под это не подгонять выходит какашка. С сетями та же история. Либо протокол уродский, либо систему типов, описывающих сетевое API приходится сильно урезать.

S>> C# прекрасно натягивается.

НС>Я просто напомню, что LINQ был придуман для того чтобы прекрасно натягивающийся шарп все таки научился хорошо работать с РСУБД без войны с системой типов.

Ну Nullable типы появились до Linq.
НС>>>А замапить JSON на сложные типы в 2022 году совершенно не проблема.
S>> Ну вот сам JSON анахронизм для 2022 года.

НС>Bullshit bingo! Опять пустые лозунги.


НС>>>При чем тут многопоточность?

S>> Ну при том, что в браузере нет многопоточности

НС>Какое это имеет отношение к API для сети?

А то, что HTTP/2 использует мультиплексирование
S>>и не используется двухканальный режим чтения и записи

НС>Может потому что дуплекс фигово работает в глобальных сетях? Да не, не может быть

С чего так? TCP/IP на том же Web сокетах прекрасно работает.

S>>>> Ну есть gRPC и в конце концов можно gRPC-Web или сервер микс gRPC c Json

НС>>>И нафига?
S>>Для таких как ты,

НС>О, перешел на личности. Со сливом.

Не личности, таких как ты (а не тебе лично) предпочитающих REST gRPC. Или все расписывать надо?
НС>>>В чем тио больше, в чем то меньше
S>>А в чем меньше?

НС>В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?

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

HTTP/2 и протобуф перекрывает этот малюсенький велосипед. Компонентов кэширования вагон и тележка. Но если для тебя важее сетевая инфраструктура кэширования.
Ок HTTP/2 идет лесом. Но таких сценариев ооочень мало. Анахронизм

НС>>>SOAP похоронил сам себя, ибо идея OORPC нежизнеспособна. Либо получается неудобное, ненадежное и тормозное чудовище, либо SOAP урезается до крайне примитивных протоколов.

S>>А gRPC это не OORPC?

НС>Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.

Ну он мультиязыковый. Там как раз типы прото прекрасно ложатся на язык.
Так же как JSON сериализация десериализация из типов тех же C#. И вызовы прекрасно мапятся на методы. Swagger это все тот же OORPC только с ограничениями на типы и HTTP/1
Только вот типов значительно больше!!
и солнце б утром не вставало, когда бы не было меня
Отредактировано 26.06.2022 16:16 Serginio1 . Предыдущая версия . Еще …
Отредактировано 26.06.2022 16:05 Serginio1 . Предыдущая версия .
Отредактировано 26.06.2022 15:50 Serginio1 . Предыдущая версия .
Отредактировано 26.06.2022 15:42 Serginio1 . Предыдущая версия .
Re[20]: язык (source of truth) будет язык схемы для этого JSON
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.06.22 16:47
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да, принципы иные. К примеру, в rest есть такой принцип: к одному экземпляру ресурса доступ может быть только по одному url.
Нет, это не обязательно так.
Регулярно встречаю паттерн, когда можно пойти по урлу https://graph.windows.net/myOrganization/users, а можно — https://graph.windows.net/66903593-1a95-4206-85cf-30b560aaec27/users

НС>В каких то ситуациях хорошо, в каких то — не очень. Все зависит от того что реже всего меняется. Если спецификация зафиксирована и меняется гораздо реже кода — code first подход будет порождать проблемы.

+1
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: язык (source of truth) будет язык схемы для этого JSON
От: Ночной Смотрящий Россия  
Дата: 26.06.22 18:44
Оценка:
Здравствуйте, Sinclair, Вы писали:

НС>>Да, принципы иные. К примеру, в rest есть такой принцип: к одному экземпляру ресурса доступ может быть только по одному url.

S>Нет, это не обязательно так.

Канонично — именно так. И оно не на ровном месте выдумано. Кеширование, к примеру, без этого будет работать хуже.

S>Регулярно встречаю паттерн, когда можно пойти по урлу https://graph.windows.net/myOrganization/users, а можно — https://graph.windows.net/66903593-1a95-4206-85cf-30b560aaec27/users


Я тебе больше скажу — практически любое сложное API принципы обязательно какие то нарушает. Но это не повод объявлять их несуществующими или бесполезными.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: язык (source of truth) будет язык схемы для этого JS
От: Ночной Смотрящий Россия  
Дата: 26.06.22 18:44
Оценка: +1
Здравствуйте, rudzuk, Вы писали:

НС>> В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?

R>Время идет, мантры все те же...

Это не мантры, это реальность. Да, она все таже, какие новые серебрянные пули не придумывай.

R>Да с этим вашим "работающим" из коробки кешированием уже все говна наелись, наелись настолько, что впендюривают в урл рандом, доп. параметром.


В REST API? Уверен? Со статикой не путаешь?
Это я уже не говорю про то что есть Cache-Control сотоварищи.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: язык (source of truth) будет язык схемы для этого JS
От: Ночной Смотрящий Россия  
Дата: 26.06.22 18:44
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

НС>>Теперь попробуй доказать что унаследованные от него ограничения критичны для коммуникаций.

S>https://russianblogs.com/article/2086122683/
S>

S>HTTP / 2 не определяет JavaScript API и не поможет вам с легкостью создать REST API. В настоящее время клиенты JavaScript, работающие в веб-браузерах, имеют ограниченное использование новых функций. Однако для обмена данными между серверами HTTP / 2 предоставляет множество способов выйти за рамки существующих API REST.


Ничего не понял. Где связь?

НС>>Я просто напомню, что LINQ был придуман для того чтобы прекрасно натягивающийся шарп все таки научился хорошо работать с РСУБД без войны с системой типов.

S>Ну Nullable типы появились до Linq.

При чем тут nullable типы? Анонимные типы тоже до LINQ появились? Или у статических языков не происходят обосратушки при попытке оборачивать кортежи РСУБД?

НС>>Какое это имеет отношение к API для сети?

S> А то, что HTTP/2 использует мультиплексирование

Bullshit bingo!

НС>>Может потому что дуплекс фигово работает в глобальных сетях? Да не, не может быть

S> С чего так?

С того.

S> TCP/IP на том же Web сокетах прекрасно работает.


Веб-сокреты это не TCP/IP. Это специальный протокол. Который, кстати, совсем не без проблем. А дуплексный gRPC никто вменяемый в глобальную сеть не выставляет. Каноничная архитектура сейчас — gRPC внутри кластера и REST снаружи.

НС>>В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?

S> А самому кэшировать никак?

Будем переписывать все кеширующие RP, включая железные? Браузер тоже свой напишем и впихнем его всем клиентам?

S> Да и лучше самому заняться


Велосипедостроение — в другое окошко.

НС>>Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.

S> Ну он мультиязыковый.

И чо? Корба и DCOM — тоже мультиязыковые, что не отменяет того факта что это OORPC со всеми вытекающими включая то, что они закономерно стухли.

S> Только вот типов значительно больше!!


И какой с того профит?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[23]: язык (source of truth) будет язык схемы для этого JS
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.06.22 07:51
Оценка: -1
Здравствуйте, Ночной Смотрящий, Вы писали:


НС>>>Я просто напомню, что LINQ был придуман для того чтобы прекрасно натягивающийся шарп все таки научился хорошо работать с РСУБД без войны с системой типов.

S>>Ну Nullable типы появились до Linq.

НС>При чем тут nullable типы? Анонимные типы тоже до LINQ появились? Или у статических языков не происходят обосратушки при попытке оборачивать кортежи РСУБД?


С анонимными типами согласен. А вот кортежи это как раз Nullable
НС>>>Какое это имеет отношение к API для сети?

S>> TCP/IP на том же Web сокетах прекрасно работает.


НС>Веб-сокреты это не TCP/IP. Это специальный протокол. Который, кстати, совсем не без проблем. А дуплексный gRPC никто вменяемый в глобальную сеть не выставляет. Каноничная архитектура сейчас — gRPC внутри кластера и REST снаружи.

С чего бы? https://ru.wikipedia.org/wiki/WebSocket

WebSocket — протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером, используя постоянное соединение.


Ну и основная фича HTTP/2 это как раз мульплексирование.
Можно поподробнее про проблемы Веб-сокреты и мульплексирования?

НС>>>В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?

S>> А самому кэшировать никак?

НС>Будем переписывать все кеширующие RP, включая железные? Браузер тоже свой напишем и впихнем его всем клиентам?

Будем использовать HTTP/2 в котором нет идемпотентности. Но опять же можно совмещать gRPC и REST c минимумом телодвижений.


НС>>>Зависит от того как его использовать. Если как пытаешься ты, с глубогой увязкой в систему типов ОО языка — безусловно.

S>> Ну он мультиязыковый.

НС>И чо? Корба и DCOM — тоже мультиязыковые, что не отменяет того факта что это OORPC со всеми вытекающими включая то, что они закономерно стухли.

DCOM кстати до сих пор прекрасно работает. Посмотри на Com surrogate в процессах.
Опять же ты проигнорировал SWAGGER и то, что над REST строится всё та же OORPC
S>> Только вот типов значительно больше!!

НС>И какой с того профит?

Профит, что нет потерь и контроль. Тот же BigInt зачем был введен?
и солнце б утром не вставало, когда бы не было меня
Re[24]: язык (source of truth) будет язык схемы для этого JS
От: Ночной Смотрящий Россия  
Дата: 27.06.22 08:52
Оценка:
Здравствуйте, Serginio1, Вы писали:

НС>>При чем тут nullable типы? Анонимные типы тоже до LINQ появились? Или у статических языков не происходят обосратушки при попытке оборачивать кортежи РСУБД?

S>С анонимными типами согласен.

Ну вот с сетевыми коммуникациями все тоже самое.

S> А вот кортежи это как раз Nullable


Опять какой то бред полился.

НС>>Веб-сокреты это не TCP/IP. Это специальный протокол. Который, кстати, совсем не без проблем. А дуплексный gRPC никто вменяемый в глобальную сеть не выставляет. Каноничная архитектура сейчас — gRPC внутри кластера и REST снаружи.

S>С чего бы?

С наблюдаемой реальности.

S> https://ru.wikipedia.org/wiki/WebSocket

S>

S>WebSocket — протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером, используя постоянное соединение.


Ты не поверишь, но HTTP это тоже "протокол связи поверх TCP-соединения"

НС>>Будем переписывать все кеширующие RP, включая железные? Браузер тоже свой напишем и впихнем его всем клиентам?

S> Будем использовать HTTP/2 в котором нет идемпотентности.



S>Опять же ты проигнорировал SWAGGER и то, что над REST строится всё та же OORPC


Нет.

НС>>И какой с того профит?

S> Профит, что нет потерь и контроль.

Каких потерь, какого конгтроля?

S> Тот же BigInt зачем был введен?


У рыбы нет шерсти.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[25]: язык (source of truth) будет язык схемы для этого JS
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.06.22 10:25
Оценка: -1
Здравствуйте, Ночной Смотрящий, Вы писали:


НС>>>Веб-сокреты это не TCP/IP. Это специальный протокол. Который, кстати, совсем не без проблем. А дуплексный gRPC никто вменяемый в глобальную сеть не выставляет. Каноничная архитектура сейчас — gRPC внутри кластера и REST снаружи.

S>>С чего бы?

НС>С наблюдаемой реальности.

Ну ты бы хоть ссылочку дал. Какие именно проблемы
S>> https://ru.wikipedia.org/wiki/WebSocket
S>>

S>>WebSocket — протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером, используя постоянное соединение.


НС>Ты не поверишь, но HTTP это тоже "протокол связи поверх TCP-соединения"

Да только это касается заголовков для соединение. А дальше на постоянном соединении идет обмен.
TCP/IP скорость обмена
НС>>>Будем переписывать все кеширующие RP, включая железные? Браузер тоже свой напишем и впихнем его всем клиентам?
S>> Будем использовать HTTP/2 в котором нет идемпотентности.

НС>

В чем facepalm? Ну то есть HTTP/2 идет боком ибо в нем нет идемпотентности? Или он есть?
S>>Опять же ты проигнорировал SWAGGER и то, что над REST строится всё та же OORPC

НС>Нет.



Ты хоть ссылки давай на свои доводы, где все расписано. Мне интересно. А верить просто я не хочу
и солнце б утром не вставало, когда бы не было меня
Re[26]: язык (source of truth) будет язык схемы для этого JS
От: scf  
Дата: 27.06.22 10:44
Оценка: +2
Здравствуйте, Serginio1, Вы писали:

S> Ты хоть ссылки давай на свои доводы, где все расписано. Мне интересно. А верить просто я не хочу


Немного личного опыта: если оппонент задает больше одного вопроса, не нужно ему отвечать.
Re[23]: gRPC vs rest
От: Sharov Россия  
Дата: 27.06.22 14:55
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>> TCP/IP на том же Web сокетах прекрасно работает.

НС>Веб-сокреты это не TCP/IP. Это специальный протокол. Который, кстати, совсем не без проблем. А дуплексный gRPC никто вменяемый в глобальную сеть не выставляет. Каноничная архитектура сейчас — gRPC внутри кластера и REST снаружи.

А rest типа не дуплексный? В чем разница grcp и rest для глобальной сети, если оба работают поверх tcp?
Почему grpc не может быть снаружи, а rest внутри?

ЗЫ: Понял, брандмауэр. Все блокировано, кроме 80. Т.е. абы кто не может никуда стукануться, кроме 80 порта. Тогда ясно. Но вопрос осталю, может
я неправ.
Кодом людям нужно помогать!
Re[24]: gRPC vs rest
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.06.22 15:37
Оценка:
Здравствуйте, Sharov, Вы писали:


S>ЗЫ: Понял, брандмауэр. Все блокировано, кроме 80. Т.е. абы кто не может никуда стукануться, кроме 80 порта. Тогда ясно. Но вопрос осталю, может

S>я неправ.

Ну HTTP/2 тоже может и на 80 и на 443 ssl http2
https://habr.com/ru/company/infobox/blog/268599/

Ну а так HTTP/2

Добавить механизмы согласования протокола, клиент и сервер могут использовать HTTP 1.1, 2.0 или, гипотетически, иные, не HTTP-протоколы.
Поддержать совместимость с многими концепциями HTTP 1.1, например по набору методов доступа (GET, PUT, POST и т. п.), статусным кодам, формату URI, большому количеству заголовков
Уменьшение задержек доступа для ускорения загрузки страниц, в частности путём:
Сжатия данных в заголовках HTTP
Использования push-технологий на серверной стороне
Конвейеризации запросов
Устранения проблемы блокировки «head-of-line» протоколов HTTP 1.0/1.1
Мультиплексирования множества запросов в одном соединении TCP
Сохранение совместимости с широко внедрёнными применениями HTTP, в том числе с веб-браузерами (полноценными и мобильными), API, используемыми в Интернете, веб-серверами, прокси-серверами, обратными прокси-серверами, сетями доставки контента


То есть и идемпотентность должен поддерживать раз совместима с GET

https://habr.com/ru/company/nix/blog/594391/

мультиплексирование (в HTTP 1.1 для передачи трех файлов надо установить три соединения, в каждом из которых будет запрашиваться и отправляться определенный файл. В HTTP/2 можно все передать по одному соединению);

и солнце б утром не вставало, когда бы не было меня
Отредактировано 27.06.2022 15:43 Serginio1 . Предыдущая версия .
Re[24]: gRPC vs rest
От: Ночной Смотрящий Россия  
Дата: 27.06.22 16:38
Оценка:
Здравствуйте, Sharov, Вы писали:

S>А rest типа не дуплексный?


Только с long polling/WebSoсkets в комплекте.

S>В чем разница grcp и rest для глобальной сети, если оба работают поверх tcp?


Как раз в свойствах полученного API. Построенный по идеологии RPC протокол плохо работает в сетях с большими и непрогнозируемыми задержками и сбоями, фигово масштабируется. И gRPC, который все таки заставляют в high load наружу работать стремительно превращается в подобие REST, обрастая спецификой сетевого взаимодействия и балансировки. В сухом остатке только бинарный protobuf, который не сказать чтобы прям такое огромное преимущество.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[25]: gRPC vs rest
От: Sharov Россия  
Дата: 27.06.22 17:08
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>В чем разница grcp и rest для глобальной сети, если оба работают поверх tcp?

НС>Как раз в свойствах полученного API. Построенный по идеологии RPC протокол плохо работает в сетях с большими и непрогнозируемыми задержками и сбоями, фигово масштабируется. И gRPC, который все таки заставляют в high load наружу работать стремительно превращается в подобие REST, обрастая спецификой сетевого взаимодействия и балансировки. В сухом остатке только бинарный protobuf, который не сказать чтобы прям такое огромное преимущество.

Не очень я этот момент понимаю -- tcp тут и там, запрос\ответ тут и там. В чем разница тогда? Soap это тот же http, но он rpc, а в чем его отличие от rest для масштабируемости?
Только ли в инфраструктуре -- RP, кэши и т.п.? Потому как повторюсь, tcp всюду, запрос\ответ всюду.
Кодом людям нужно помогать!
Re[26]: gRPC vs rest
От: Ночной Смотрящий Россия  
Дата: 27.06.22 19:49
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:

S>Не очень я этот момент понимаю -- tcp тут и там, запрос\ответ тут и там. В чем разница тогда?


Тут недавно был топик. Обсуждали API управления камерой. RPC style это методы Move, Rotate, Scale. REST style — методы PUT Position, PUT Angle, PUT Scale. Домашнее задание — какие будут эффекты от обрыва связи в первом и втором случае, как от них будем защищаться? Что произойдет если латентность соединения — единицы секунд? Что произойдет если понадобится доступ нескольких клиентов?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[27]: gRPC vs rest
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.06.22 09:56
Оценка: -1
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Тут недавно был топик. Обсуждали API управления камерой. RPC style это методы Move, Rotate, Scale. REST style — методы PUT Position, PUT Angle, PUT Scale. Домашнее задание — какие будут эффекты от обрыва связи в первом и втором случае, как от них будем защищаться? Что произойдет если латентность соединения — единицы секунд? Что произойдет если понадобится доступ нескольких клиентов?

Угу охринительный пример про сервер на камере! IoT кстати говорили про 5G!
Пока эпоха IoT не наступила, а gRPC это все таки про сервера, а не про IoT с хреновой связью и мощностью.
Там небось и поддержки HTTP/2 то нет.
Там кстати и свой протокол https://iot.ru/wiki/protokoly-peredachi-dannykh-iot
и солнце б утром не вставало, когда бы не было меня
Отредактировано 28.06.2022 10:19 Serginio1 . Предыдущая версия .
Re[28]: gRPC vs rest
От: Ночной Смотрящий Россия  
Дата: 28.06.22 11:08
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Угу охринительный пример про сервер на камере!


Отличный пример, демонстрирующий разницу в REST и RPC подходах.

S> IoT кстати говорили про 5G!


Bullshit bingo!

S>Там небось и поддержки HTTP/2 то нет.


Bullshit bingo!
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[29]: gRPC vs rest
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.06.22 11:39
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Serginio1, Вы писали:


S>> Угу охринительный пример про сервер на камере!


НС>Отличный пример, демонстрирующий разницу в REST и RPC подходах.


RPC прекрасно создается и на REST. Не важно, как объектная модель использует транспорт. С токи зрения программиста он создает параметры и вызывает метод.
А дальше REST, gRPC не суть. REST это всего на всего набор правил для HTTP протокола
https://ru.wikipedia.org/wiki/REST

В интернете вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса[3][4].


Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.


S>>Там небось и поддержки HTTP/2 то нет.


НС>Bullshit bingo!

Угу при этом для тех же IoT используются немного другие протоколы, для уменьшения трафика. Проблема не в RPC как таковом. Проблема в сериализации десериализации и транспорте.
Тот же Swagger и OpenApi как раз и решают проблему OORPC

.Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед
и солнце б утром не вставало, когда бы не было меня
Отредактировано 28.06.2022 11:48 Serginio1 . Предыдущая версия .
Re[30]: gRPC vs rest
От: Ночной Смотрящий Россия  
Дата: 28.06.22 13:03
Оценка:
Здравствуйте, Serginio1, Вы писали:

НС>>Отличный пример, демонстрирующий разницу в REST и RPC подходах.

S>RPC прекрасно создается и на REST.

gRPC ты хотел сказать? Иначе написанное тобой выглядит как бред.

S> Не важно, как объектная модель использует транспорт.


Именно это и важно если мы говорим о REST.

S>А дальше REST, gRPC не суть.


Еще как суть. А ты явно не понимаешь что такое REST и думаешь что это очередной RPC на базе JSON.

S> REST это всего на всего набор правил для HTTP протокола


Это набор архитектурных принципов. По твоей же ссылке:

REST (от англ. Representational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль...


S>>>Там небось и поддержки HTTP/2 то нет.

НС>>Bullshit bingo!
S> Угу при этом для тех же IoT используются немного другие протоколы

У тебя проблемы с пониманием написанного. REST это архитектурный стиль, а не протоколы.

S> Тот же Swagger и OpenApi как раз и решают проблему OORPC


Нет.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.