Здравствуйте, bitboi, Вы писали:
C>>Почему же? Оно "набирает" номер другой стороны. B>ну типа мы набираем номер другой стороны и ждем когда нас соединят, получается что dial это только первая часть процесса B>плюс у меня еще ассоциации с signalling в VoIP появляются
Ну так и есть. Connect/Dial делают попытку соединиться с удалённой стороной, на что удалённая сторона должна ответить ("поднять трубку").
C>>Это практически единственный пример, где оно не работает. Но если очень хочется — берём и вызываем clock_gettime напрямую. B>мне кажется можно придумать еще, но главное конечно, это то что теряется аспект документирования кода и интерфейсов B>скажем если я вижу где-то в интерфейсе duration и это системное время, либо наоборот монотонное, я что-то сразу понимаю про то как это все должно работать, а тут нет, мелочь конечно, но неприятно
Монотонность часов для Duration — вообще пофиг. Это разность между двумя отметками времени.
C>>Ну они могли бы ввести тип "type Path string", но смысл? Массив байт неудобен из-за того, что нельзя гарантировать иммутабельность. B>жить с этим конечно можно, но опять же, вот есть у меня ф-я, которая преобразует путь в каноничный (в Go такой ф-ии почему-то нет, но представим что есть)
Пусть преобразует.
B>так вот, ф-я получает на вход путь в виде строки? при этом она не делает то что можно подумать (преобразует строку используя только входные данные), она лезет в ФС и делает что-то сложное, использует системный вызов, который может делать какой-то ввод-вывод и тд, но ф-я выглядит так, словно она просто преобразует строку
Тогда такая функция должна бы принимать контекст и возвращать пару (string, error) в качестве результата. Будет сразу понятно, что она делает что-то сложное.
B>в общем, мое мнение — strong types это хорошо, в плюсах к этому уже давно пришли, там уже принято вводить именованные типы вместо фундаментальных, там где это имеет смысл
Ну так можно и в Go — "type Path string". Это будет сильный тип, который надо из/в строку преобразовывать явно.
Но вот честно, не вижу особых плюсов. Go — это не С++, и выдумывать сложности его разработчики не любят.
Здравствуйте, Sinclair, Вы писали:
_>>Нюанс в том, что в данный момент основным подходом снова становится RPC. Правда теперь это уже RPC поверх HTTP/2 (gRPC), но это не суть (тут https играет роль не сильно большую, чем tcp, ip, ethernet). ))) S>Интересно, с чем это связано. Что именно компенсирует недостатки RPC по сравнению с REST?
Конкретно с gRPC — полноценная двусторонняя коммуникация.
Ну и в целом, REST весьма неудобен как подход, в целом. Слишком много гибкости.
Здравствуйте, Sinclair, Вы писали:
_>>Нюанс в том, что в данный момент основным подходом снова становится RPC. Правда теперь это уже RPC поверх HTTP/2 (gRPC), но это не суть (тут https играет роль не сильно большую, чем tcp, ip, ethernet). ))) S>Интересно, с чем это связано. Что именно компенсирует недостатки RPC по сравнению с REST?
Не берусь высказываться за глобальные причины (почему мир переходит), могут высказаться только о своих ощущениях. И эти ощущения представляют в основном список из нескольких пунктов убожества REST (причём я буду говорить не о теоретических определениях этой архитектуры, а о свойствах общепринятых практических реализаций):
1. Максимально убогая сериализация. Т.е. в том же gRPC используется далеко не идеальный Protocol Buffers (например MessagePack намного эффективнее), но по сравнению со стандартным подходом сериализации из REST, это просто мегашедевр эффективности. )))
2. Несимметричные возможности у клиента и сервера. По сути REST — это однонаправленный протокол, в то время как в gRPC после установки соединения сервер может спокойно инициировать отсылку данных клиенту.
3. Одновременная и убогость и излишество базовых методов REST (которые наследие HTTP). Это наверное самый важных архитектурный пункт, так что поясню подробнее. При использование REST возможны два разных архитектурных подхода:
— использование базовых методов в качестве набора команд (API) нашего сервиса. Очевидно, что это подходит только для максимально простеньких задач, целиком укладывающихся в CRUD. И тут чувствуется вся убогость этого набора команд.
— использование удобного нетривиального API, реальные команды которого передаются в REST запросах в качестве данных (параметров). Т.е. в этом случае REST уже служит просто очередным сетевым слоем (ниже прикладного), правда достаточно не эффективным. И в этом случае наоборот очевидно излишество базовых методов (в принципе одного POST достаточно для передачи любой прикладной команды).
В целом меня совсем не удивляет происходящий сейчас переход на gRPC. Меня скорее удивляет почему индустрия не сделала этого намного раньше, потратив десятилетие на REST убожество.
Здравствуйте, Cyberax, Вы писали:
S>>Интересно, с чем это связано. Что именно компенсирует недостатки RPC по сравнению с REST? C>Конкретно с gRPC — полноценная двусторонняя коммуникация.
Ну, по моему опыту, любая RPC-style коммуникация — это какой трэш. В основном — потому, что не умеет в передачу распределённого состояния.
То есть в нормальный протокол, рассчитанный на применение в сети, должны быть заложены концепции safety и idempotence.
C>Ну и в целом, REST весьма неудобен как подход, в целом. Слишком много гибкости.
Непонятно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Если вернуться к истокам, то ООП было изобретено для многооконного GUI. Интересно разобраться, как рисовать гую на ФП — сильно хуже, чем в ООП, а то может быть и лучше.
Самое смешное, что Go (ну ОК, Newsqueak) был тоже изобретен для многооконного GUI
Здравствуйте, alex_public, Вы писали:
_>1. Максимально убогая сериализация. Т.е. в том же gRPC используется далеко не идеальный Protocol Buffers (например MessagePack намного эффективнее), но по сравнению со стандартным подходом сериализации из REST, это просто мегашедевр эффективности. )))
Да, хороший поинт. Впрочем, сам REST ничего про сериализацию не говорит. Если state, который мы передаём, хорошо описывается MessagePack, то почему бы не передавать его MessagePack?
Но есть у меня подозрение, что для REST MessagePack мало что даст. Ну, из банального — там есть очевидный, механический способ построить delta-encoding?
_>2. Несимметричные возможности у клиента и сервера. По сути REST — это однонаправленный протокол, в то время как в gRPC после установки соединения сервер может спокойно инициировать отсылку данных клиенту.
Ну, сделать reliable two-way state transfer ещё тяжелее, чем однонаправленный. Я пока что не очень представляю себе задачу, где это было бы уместно с точки зрения архитектуры.
То есть если нас устраивает ненадёжность — то без проблем, можно делать двусторонние каналы. А если нужна надёжность — то рисковать полагаться на клиента, который может лечь...
_>3. Одновременная и убогость и излишество базовых методов REST (которые наследие HTTP). Это наверное самый важных архитектурный пункт, так что поясню подробнее. При использование REST возможны два разных архитектурных подхода: _>- использование базовых методов в качестве набора команд (API) нашего сервиса. Очевидно, что это подходит только для максимально простеньких задач, целиком укладывающихся в CRUD. И тут чувствуется вся убогость этого набора команд.
Нет конечно. Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл.
В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.
_>- использование удобного нетривиального API, реальные команды которого передаются в REST запросах в качестве данных (параметров). Т.е. в этом случае REST уже служит просто очередным сетевым слоем (ниже прикладного), правда достаточно не эффективным. И в этом случае наоборот очевидно излишество базовых методов (в принципе одного POST достаточно для передачи любой прикладной команды).
Это банальный антипаттерн. Никакогог REST тут нету, а есть RPC over HTTP. Его крайним развитием является SOAP, место которого — в аду.
_>В целом меня совсем не удивляет происходящий сейчас переход на gRPC. Меня скорее удивляет почему индустрия не сделала этого намного раньше, потратив десятилетие на REST убожество.
Хм. Пока что не вижу аргументов, кроме какого-то непонимания REST.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>1. Максимально убогая сериализация. Т.е. в том же gRPC используется далеко не идеальный Protocol Buffers (например MessagePack намного эффективнее), но по сравнению со стандартным подходом сериализации из REST, это просто мегашедевр эффективности. )))
кто-то запрещает передавать в ответе бинарные данные?
_>3. Одновременная и убогость и излишество базовых методов REST (которые наследие HTTP). Это наверное самый важных архитектурный пункт, так что поясню подробнее. При использование REST возможны два разных архитектурных подхода: _>- использование базовых методов в качестве набора команд (API) нашего сервиса. Очевидно, что это подходит только для максимально простеньких задач, целиком укладывающихся в CRUD. И тут чувствуется вся убогость этого набора команд.
тут чувствуется возможность на уровне прикси-сервера распределять нагрузку ничего не зная о реализации конкретных ендпоинтов.
например отправлять гет запросы только на приложения, работающие с зеркалом основной базы.
_>- использование удобного нетривиального API, реальные команды которого передаются в REST запросах в качестве данных (параметров). Т.е. в этом случае REST уже служит просто очередным сетевым слоем (ниже прикладного), правда достаточно не эффективным. И в этом случае наоборот очевидно излишество базовых методов (в принципе одного POST достаточно для передачи любой прикладной команды).
Здравствуйте, Sheridan, Вы писали:
НС>>Могу S>Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно? Что с эволюцией делать будем?
Ты про биологическую эволюцию?
Ну видимо, будем есть задницей, раз все млекопитающие произошли от кишечнополостных, а у них одна дырка для всех целей. И метать икру; рыбка у нас тоже в предках.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sheridan, Вы писали:
НС>>>Могу S>>Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно?
НС>Абсолютно. Нет в реальном мире наследования за пределами биологии. Есть множество разнотипных связей, жесткая редукция которых до иерархического однонаправленного графа со строго одним типом связи ни к чему хорошему не приводит.
В биологии ее тоже нет. Есть биологическая классификация, но она про то, как нам удобнее помыслить о биологических объектах, а не про их собственную жизнь. Собаке абсолютно все равно, к какому классу, виду и отряду она относится, ей бы косточку, и чтобы поиграли (но от огурчика она тоже не откажется, хоть и плотоядная).
И даже в классификации есть куча исключений, потому, что реальная жизнь учебников по биологии не читала, и в классификацию так себе укладывается.
Здравствуйте, Pzz, Вы писали:
НС>>>Могу S>>Первый же пункт, про наследование которое не имеет отражений в реальном мире. Серьёзно? Что с эволюцией делать будем? Pzz>Ты про биологическую эволюцию? Pzz>Ну видимо, будем есть задницей, раз все млекопитающие произошли от кишечнополостных, а у них одна дырка для всех целей. И метать икру; рыбка у нас тоже в предках. man онтогенез
Здравствуйте, Sinclair, Вы писали:
_>>1. Максимально убогая сериализация. Т.е. в том же gRPC используется далеко не идеальный Protocol Buffers (например MessagePack намного эффективнее), но по сравнению со стандартным подходом сериализации из REST, это просто мегашедевр эффективности. ))) S>Да, хороший поинт. Впрочем, сам REST ничего про сериализацию не говорит. Если state, который мы передаём, хорошо описывается MessagePack, то почему бы не передавать его MessagePack?
Ну для начала не стоит забывать про то, что в REST у тебя для части данных жёстко определён способ сериализации, причём максимально убогий — urlencoded .
А далее, даже если мы возьмём MessagePack и HTTP/2 для REST, то это всё равно не позволит нам получить сравнимую эффективность из-за наличия в gRPC такого "типа данных" как stream. Который позволяет отправить множество сообщений в рамках одного запроса (а не проводить весь комплекс установки ip, tcp, http, ssl соединений для каждой маленькой пачки данных).
S>Но есть у меня подозрение, что для REST MessagePack мало что даст. Ну, из банального — там есть очевидный, механический способ построить delta-encoding?
Эээ что? )
_>>2. Несимметричные возможности у клиента и сервера. По сути REST — это однонаправленный протокол, в то время как в gRPC после установки соединения сервер может спокойно инициировать отсылку данных клиенту. S>Ну, сделать reliable two-way state transfer ещё тяжелее, чем однонаправленный. Я пока что не очень представляю себе задачу, где это было бы уместно с точки зрения архитектуры.
Могу привести тебе пример такой задачи. Более того, решаемой прямой сейчас в работающих системах именно таким способом. Например это получение клиентом данных о биржевой торговле (стакан и т.п.) в реальном времени.
S>То есть если нас устраивает ненадёжность — то без проблем, можно делать двусторонние каналы. А если нужна надёжность — то рисковать полагаться на клиента, который может лечь...
Типа если клиент с REST ляжет, то это как-то поможет не забыть отреагировать в нужный момент на текущие данные? )))
_>>3. Одновременная и убогость и излишество базовых методов REST (которые наследие HTTP). Это наверное самый важных архитектурный пункт, так что поясню подробнее. При использование REST возможны два разных архитектурных подхода: _>>- использование базовых методов в качестве набора команд (API) нашего сервиса. Очевидно, что это подходит только для максимально простеньких задач, целиком укладывающихся в CRUD. И тут чувствуется вся убогость этого набора команд. S>Нет конечно. Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл. S>В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.
Ну вот тебе простейшая (и опять же из вполне реальной практики) задачка. Есть шаговый манипулятор со свободным вращением (но без энкодера). И соответственно у управляющей им схемы есть две команды: move_left() и move_right(). Доступ к этому через RPC очевидно выглядит полностью естественно — прямо как и реальные команды. А вот как по твоему будет выглядеть логичный REST вариант интерфейса? )))
_>>В целом меня совсем не удивляет происходящий сейчас переход на gRPC. Меня скорее удивляет почему индустрия не сделала этого намного раньше, потратив десятилетие на REST убожество. S>Хм. Пока что не вижу аргументов, кроме какого-то непонимания REST.
Ну возможно это мои личные субъективные ощущения (а индустрия возвращается к RPC по каким-то другим причинам), а возможно ты слепой (не видишь аргументов, а они есть). Не знаю.
Здравствуйте, Hobbes, Вы писали:
H>Контракт может сохраняться, я не спорю. Но зачем делать так:
H>Когда логичнее так:
Потому что классическое ООП наследование это два в одном — наследование контрактов и наследование реализаций. Когда нужно что то одно (а обычно оно так и нужно) — то второе идет ненужным довеском. Для наследования контрактов в языках посовременне придумали понятие интерфейсов. А вот с наследованием реализаций все плохо, private наследование в плюсах это какой то уродливый франкенштейн.
В некоторых языках есть миксины/трейты/шейпы/етц, и есть всякие паттерны. Но это все сильно усложняет дизайн. Как по мне, тут просто ООП не годится, и дизайн в ФП стиле, с функциями, намного чище.
Здравствуйте, alex_public, Вы писали:
_>Ну для начала не стоит забывать про то, что в REST у тебя для части данных жёстко определён способ сериализации, причём максимально убогий — urlencoded .
А что у нас в gRPC? Там же внизу тот же HTTP, то есть адресация по прежнему через URL.
_>А далее, даже если мы возьмём MessagePack и HTTP/2 для REST, то это всё равно не позволит нам получить сравнимую эффективность из-за наличия в gRPC такого "типа данных" как stream. Который позволяет отправить множество сообщений в рамках одного запроса (а не проводить весь комплекс установки ip, tcp, http, ssl соединений для каждой маленькой пачки данных).
Не очень понятно, что нам помешает отправить в REST пачку данных в рамках одного запроса или реквеста.
Большинство REST-данных именно так и устроены. Более того — в RPC вы не сможете получить сравнимую с REST эффективность из-за отсутствия conditional get и delta encoding.
_>Эээ что? )
Сказать серверу "данные вплоть до 18.02 у меня уже есть. Если есть что-то новее — то пришлите разницу. Если нет — то достаточно просто 304".
_>Могу привести тебе пример такой задачи. Более того, решаемой прямой сейчас в работающих системах именно таким способом. Например это получение клиентом данных о биржевой торговле (стакан и т.п.) в реальном времени.
Ну, про биржевую торговлю я не специалист. Те клиенты, которыми я пользовался, работают поверх REST. Никакого gRPC. Но я понимаю, что там всё для людей — роботам нужно что-то другое; для чего вебхуки категорически не подойдут. S>>То есть если нас устраивает ненадёжность — то без проблем, можно делать двусторонние каналы. А если нужна надёжность — то рисковать полагаться на клиента, который может лечь...
_>Типа если клиент с REST ляжет, то это как-то поможет не забыть отреагировать в нужный момент на текущие данные? )))
Типа если REST-клиент ляжет, это никак не повлияет на поведение сервера. А ставить поведение всей системы в зависимость от того, смог ли клиент получить данные немедленно или нет — это путь к катастрофе.
_>Ну вот тебе простейшая (и опять же из вполне реальной практики) задачка. Есть шаговый манипулятор со свободным вращением (но без энкодера). И соответственно у управляющей им схемы есть две команды: move_left() и move_right(). Доступ к этому через RPC очевидно выглядит полностью естественно — прямо как и реальные команды. А вот как по твоему будет выглядеть логичный REST вариант интерфейса? )))
Погодите, у вас где-то за океаном стоит шаговый манипулятор, и вы хотите управлять им через RPC, я правильно понял?
И вас никак-никак не беспокоит то, что вы не имеете представления о его текущем положении?
По-моему, эта схема архитектурно обречена. Чтобы спроектировать нормальное решение, надо начать плясать от задачи, а не от "у нас есть шаговый манипулятор, бутылка виски и два билета на бейсбол. Какой API нам выставить для всего этого?".
_>Ну возможно это мои личные субъективные ощущения (а индустрия возвращается к RPC по каким-то другим причинам), а возможно ты слепой (не видишь аргументов, а они есть). Не знаю.
Мне вот кажется, что индустрия просто так и не перешла на REST. Ну, то есть кто-то продолжал пилить RPC over HTTP, называя его REST — вот эти люди, понятное дело, с большим облегчением переезжают на всякие gRPC и MessagePack.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, night beast, Вы писали:
_>>3. Одновременная и убогость и излишество базовых методов REST (которые наследие HTTP). Это наверное самый важных архитектурный пункт, так что поясню подробнее. При использование REST возможны два разных архитектурных подхода: _>>- использование базовых методов в качестве набора команд (API) нашего сервиса. Очевидно, что это подходит только для максимально простеньких задач, целиком укладывающихся в CRUD. И тут чувствуется вся убогость этого набора команд. NB>тут чувствуется возможность на уровне прикси-сервера распределять нагрузку ничего не зная о реализации конкретных ендпоинтов.
Здравствуйте, 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).
Здравствуйте, alex_public, Вы писали:
NB>>тут чувствуется возможность на уровне прикси-сервера распределять нагрузку ничего не зная о реализации конкретных ендпоинтов.
_>Балансировка запросов встроена прямо в gRPC. )))
Здравствуйте, Sinclair, Вы писали:
C>>Конкретно с gRPC — полноценная двусторонняя коммуникация. S>Ну, по моему опыту, любая RPC-style коммуникация — это какой трэш. В основном — потому, что не умеет в передачу распределённого состояния. S>То есть в нормальный протокол, рассчитанный на применение в сети, должны быть заложены концепции safety и idempotence.
gRPC — это всё-таки не CORBA. В нём нет встроенных "объектных ссылок" и прочей нечисти. По сути, statefullness распространяется только на рамки одного запроса.
Потому API на gRPC проектируется по тем же принципам, что и для REST.
C>>Ну и в целом, REST весьма неудобен как подход, в целом. Слишком много гибкости. S>Непонятно.
Сериализация не стандартизована и размазана по пути запроса, query string, телу запроса, заголовкам HTTP, и даже cookies.
В gRPC всё просто — есть сообщение, с возможными метаданными (для авторизации) и всё. При этом сообщения подчиняются жёсткой схеме.
