Вот есть некий набор микросервисов с набором спецификаций на OpenAPI, который теоретически вроде как призван разрулить бардак, однако на практике у меня возникают некого рода "трудности", а именно:
- существует кодогенератор ( https://github.com/swagger-api/swagger-codegen ) который умеет генерировать интерфейсы и DTO, он мне не особо нравится, поскольку хочет чтобы я использовал OffsetDateTime, а у меня несколько иные предпочтения как работать со временем, ну да ладно, вроде как получить то что я ожидаю можно, хоть и через жопу
- в OpenAPI можно задекларировать, что на разные статусы можно возвращать разный тип результата, и с этим как-то вообще непонятно что делать, т.е. генератор в интерфейсе лепит ResponseEntity<DTOType>, а OpenAPI-спецификация разрешает в военное возвращать что-то еще (там по большей части другой результат возвращается на 4xx и 5xx и можно извернуться через выкидывание исключения, но как-то вообще криво)
- есть эндпойнты с кучей необязательных параметров (например поиск чего-то по набору полей), вот если использовать в качестве клиента jaxrs или feign, то нужно либо все эти параметры таскать за собой, либо наследовать клиентский интерфейс и в нем через default вычленять параметры, которые нужны

это так у всех или только у меня?

У меня изначальное желание такое, чтобы то что касалось протокола взаимодействия жило в отдельном модуле, а серверная и клиентская части ее бы использовали, например от одного только того, что в разных спецификациях используются одни и те же названия DTO и где-то они разные, а где-то одинаковые, у меня уже некисло бомбит, а если использовать retrofit, то оно уже само по себе подразумевает независимую клиентскую часть, поэтому думал только в сторону jaxrs и spring, вот feign спринговые аннотации умеет.

O_o, на голубиной почте нужно делать?

У меня есть запрос (не команда и не событие), ответ на который я хочу получить здесь и сейчас, а не завтра и там, зачем мне этот запрос (и ответ) складывать в условно персистентное хранилище?

Не умеет, просто потому что у вас понятие "умеет" несколько извращенное: от того что в active mq накидали какого-то стремного кода, который для вызывающей стороны выглядит как синхронный вызов, совершенно не означает что вызов действительно синхронный, т.е. никаких контрактов для отвечающей стороны здесь не появляется.

Ну просрали и просрали запрос, что с того? я же не очко пользователя ставлю. А ответ на запрос, который "не просрали", спустя минуту мне уже не нужен.

Ну все просто же: в микросервисах со стороны HTTP офигеть какой бардак (ну, например, я так более-менее приемлемого ответа на свой вопрос не получил, а то что у меня спецификации кривые я и сам знаю, однако в SOAP такого не было - там xs:any довольно редкий зверь и все знают что от него попахивает), поэтому нужно использовать для взаимодействия протоколы, которые для этого не предназначены

Вы, судя по всему, разницы между запросом и данными не видите, к тому же еще думаете, что кафка данные не просирает

ну как-как... берете и начинаете использовать active mq с костылями, отправляете туда сообщение, принимающая сторона сообщение прочесть не смогла, на вашей стороне вместо сообщения об ошибке возникает таймаут следующим этапом будет: чтобы получать сообщения об ошибках нам нужна еще DLQ, которую нужно обрабатывать, а мы всего-то хотели запрос по HTTP пульнуть