это просто был пример

Если воспринимать хттп как транспорт по которому мы гоняем данные, то тогда пост, пут, гет, это просто деталь реализации и не должна нести какой-то смысловой нагрузки, но тогда вопрос как быть с идемпотентными мутациями, если у нас протокол это просто рпс, то мы выходит теряем эту информацию и надо реализовывать её самостоятельно.

как выше написал @onokonem всем насрать до тех пор пока вы делаете всё по уму, пишете вменяемую документацию, сами придерживаетесь придуманных соглашений, хотите юзать GET POST PUT DELETE PATCH пожалуйста, не хотите юзайте только GET POST главное в кашу не превращать а четко следовать соглашению

а надо ли тогда выдумывать самому что-то если можно свести всё к json-prc?

openapi - ключевой момент. он не даст вам изобрести необозримого монстра

ну мы в чате про Go поэтому здесь имеет место выбор такой, а например в языке который не умеет в параллельное выполнение, смысла уже нет, тем более при json-rpc надо что-то думать с возможным огромным телом ответа когда на входе будет с 10-20 запросов а в теле гиг информации... или принимать отдельное соглашение что в одном реальном запросе не может быть больше одного виртуального? тогда это уже не json-rpc...

мне ещё нравился подход с вот этой либой от автора go chi

жаль оно не очень популярное

там схема, кодген и рпс в виде

http://localhost:4242/rpc/ExampleService/GetUser

Коллеги простите что поднял эту тему и снова развёлся этот холивар с апикодами😂

А можно ли его воспринимать как транспорт, когда на пути куча народу вмешивается, cdn, прокси, браузер со своими оригин политиками, всякие option запросы, сам сервер стоит между приложением и остальным миром

Да нету холивара никакого. Просто юзайте хттп коды и всё))

вот это четко, появись он раньше может и было бы единое представление,что такое рест

Ну или не юзайте

А что больше жрёт, большая мапа с функциями или цепочка обязанностей?

Так поменяйте!

цепочка чего?

Паттерн такой))