Здравствуйте, 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
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел?
Время идет, мантры все те же... Да с этим вашим "работающим" из коробки кешированием уже все говна наелись, наелись настолько, что впендюривают в урл рандом, доп. параметром.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, 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
Только вот типов значительно больше!!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Да, принципы иные. К примеру, в 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
Здравствуйте, Sinclair, Вы писали:
НС>>Да, принципы иные. К примеру, в rest есть такой принцип: к одному экземпляру ресурса доступ может быть только по одному url. S>Нет, это не обязательно так.
Я тебе больше скажу — практически любое сложное API принципы обязательно какие то нарушает. Но это не повод объявлять их несуществующими или бесполезными.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: язык (source of truth) будет язык схемы для этого JS
Здравствуйте, rudzuk, Вы писали:
НС>> В поддержке нативных для HTTP понятий. Что там насчет идемпотентности, кеширования, поддержки range? Изобретаем велосипед по новой, оставляя сетевую инфраструктуру не у дел? R>Время идет, мантры все те же...
Это не мантры, это реальность. Да, она все таже, какие новые серебрянные пули не придумывай.
R>Да с этим вашим "работающим" из коробки кешированием уже все говна наелись, наелись настолько, что впендюривают в урл рандом, доп. параметром.
В REST API? Уверен? Со статикой не путаешь?
Это я уже не говорю про то что есть Cache-Control сотоварищи.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: язык (source of truth) будет язык схемы для этого JS
Здравствуйте, 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
НС>>>Я просто напомню, что 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
Здравствуйте, Serginio1, Вы писали:
НС>>При чем тут nullable типы? Анонимные типы тоже до LINQ появились? Или у статических языков не происходят обосратушки при попытке оборачивать кортежи РСУБД? S>С анонимными типами согласен.
Ну вот с сетевыми коммуникациями все тоже самое.
S> А вот кортежи это как раз Nullable
Опять какой то бред полился.
НС>>Веб-сокреты это не TCP/IP. Это специальный протокол. Который, кстати, совсем не без проблем. А дуплексный gRPC никто вменяемый в глобальную сеть не выставляет. Каноничная архитектура сейчас — gRPC внутри кластера и REST снаружи. 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
НС>>>Веб-сокреты это не 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
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> TCP/IP на том же Web сокетах прекрасно работает. НС>Веб-сокреты это не TCP/IP. Это специальный протокол. Который, кстати, совсем не без проблем. А дуплексный gRPC никто вменяемый в глобальную сеть не выставляет. Каноничная архитектура сейчас — gRPC внутри кластера и REST снаружи.
А rest типа не дуплексный? В чем разница grcp и rest для глобальной сети, если оба работают поверх tcp?
Почему grpc не может быть снаружи, а rest внутри?
ЗЫ: Понял, брандмауэр. Все блокировано, кроме 80. Т.е. абы кто не может никуда стукануться, кроме 80 порта. Тогда ясно. Но вопрос осталю, может
я неправ.
S>ЗЫ: Понял, брандмауэр. Все блокировано, кроме 80. Т.е. абы кто не может никуда стукануться, кроме 80 порта. Тогда ясно. Но вопрос осталю, может S>я неправ.
Добавить механизмы согласования протокола, клиент и сервер могут использовать 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
мультиплексирование (в HTTP 1.1 для передачи трех файлов надо установить три соединения, в каждом из которых будет запрашиваться и отправляться определенный файл. В HTTP/2 можно все передать по одному соединению);
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sharov, Вы писали:
S>А rest типа не дуплексный?
Только с long polling/WebSoсkets в комплекте.
S>В чем разница grcp и rest для глобальной сети, если оба работают поверх tcp?
Как раз в свойствах полученного API. Построенный по идеологии RPC протокол плохо работает в сетях с большими и непрогнозируемыми задержками и сбоями, фигово масштабируется. И gRPC, который все таки заставляют в high load наружу работать стремительно превращается в подобие REST, обрастая спецификой сетевого взаимодействия и балансировки. В сухом остатке только бинарный protobuf, который не сказать чтобы прям такое огромное преимущество.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>В чем разница grcp и rest для глобальной сети, если оба работают поверх tcp? НС>Как раз в свойствах полученного API. Построенный по идеологии RPC протокол плохо работает в сетях с большими и непрогнозируемыми задержками и сбоями, фигово масштабируется. И gRPC, который все таки заставляют в high load наружу работать стремительно превращается в подобие REST, обрастая спецификой сетевого взаимодействия и балансировки. В сухом остатке только бинарный protobuf, который не сказать чтобы прям такое огромное преимущество.
Не очень я этот момент понимаю -- tcp тут и там, запрос\ответ тут и там. В чем разница тогда? Soap это тот же http, но он rpc, а в чем его отличие от rest для масштабируемости?
Только ли в инфраструктуре -- RP, кэши и т.п.? Потому как повторюсь, tcp всюду, запрос\ответ всюду.
Здравствуйте, Sharov, Вы писали:
S>Не очень я этот момент понимаю -- tcp тут и там, запрос\ответ тут и там. В чем разница тогда?
Тут недавно был топик. Обсуждали API управления камерой. RPC style это методы Move, Rotate, Scale. REST style — методы PUT Position, PUT Angle, PUT Scale. Домашнее задание — какие будут эффекты от обрыва связи в первом и втором случае, как от них будем защищаться? Что произойдет если латентность соединения — единицы секунд? Что произойдет если понадобится доступ нескольких клиентов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тут недавно был топик. Обсуждали 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
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, 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
Здравствуйте, 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