А что он в этом толке предлагает взамен рест? Очереди?

Нет) видео клевое

Как будто кроме реста ничего нету в этом мире

из заголовка выглядит как CQRS

лично мне импонирует AMQP based RPC 😊

хотя вроде одно другого не исключает https://lostechies.com/jimmybogard/2016/06/01/cqrs-and-rest-the-perfect-match/

В общих чертах его идея такая: 1) вместо rest сделать RPC-подобный протокол, то есть JSON с полями actions и params 2) все команды делятся на read-only и mutable 3) команды на чтение исполняются сразу, а на изменение уходят в кафку. В ответ на изменение приходит айди задачи, которую клиент будет трекать 4) фоновые воркеры разгребают кафку и пишут в задачу результат иили ошибку 5) в результате мы храним историю команд, ее можно переиграть. 6) За счет добавления новых воркеров система масштабируется, можно добавлять долгие задачи, например выгрузку истории, отправку писем, формирование PDF и другое

нет ли тут неудобства для маленьких проектов?

1 прям бальзам на душу, как же бесит традиционное обилие параметров разного типа напиханных куда только можно…

не ясно, как клиенту трекать задачу по пункту 3

в ответ на изменение сущности приходит json с полем job-id = xxxxxxxxxxx

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

почему-то не увидел это сообщение. Можно и вебсокеты, но если задан Keep alive, то обычные запросы будут так же работать

мы 1. применяли у себя, все запросы только POST в хидере токен, в тело - json со всеми параметрами, все. Например POST get-users, add-users и тд. Ощущения только положительные остались.

А почему только POST? Почему на рид команды не гет?

клиента будет сложней реализовывать для разного способа вызова команд, а плюсов мало учитывая нежелательность кэширования GET, плюсов с GET даже нет

мы используем это для межсервисного взаимодействия, так что все клиенты сами микросервисы

ну, в общем, я за такие решения, когда вопрошающий оставляет свой обратный адрес, куда получает ответ по готовности

Ну как раз CQRS. Комаеды кешировать не надо, конечно. А query пусть кешируются.

это неважно когда реализуешь протокол общения, то включать в него выбор между GET/POST по названию метода — избыточное усложнение

1. Читаем список 2. Выполняем команду на изменение списка 3. Перечитываем список как в 1, пусть кэшируется?

если я правильно понимаю вопрос, то POST

так тоже можно, если речь о сервисах. А если получатель это клиент, то как он оставит свой урл для нотификации? Только долбиться остается

вот и я ему так ответил, что «так проще»

ну, бывают же клиенты с постоянным подключением к чему-нибудь, на тех же вебсокетах

🤦‍♂️ ага, я тепреь понял, а сначала запутался)

можно и с лонг поллингом через прокси 😊

а зачем разные эндпойнты вообще?

чтобы было видно что торчит из микросервиса, описание было. Эндпоинты может support команда дернуть

а, ну только если для этого, так-то никто не мешает упаковать всё в одну json-ку

в больших проектах "в одну жсонку" это крайность. Везде нужен компромис

Я такое практикую.