Вот есть некий набор микросервисов с набором спецификаций на 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 пульнуть

Для чего "для этого"? В случае взаимодействия по HTTP существует три возможных исхода:
- какой-то вменяемый ответ
- ошибка
- таймаут (фактически ошибка, но после ее возникновения состояние системы становится непонятным)

асинхронное взаимодействие (в т.ч. использование очередей) в первую очередь направлено на борьбу с таймаутами, потому что компенсировать в коде таймауты довольно трудоемко, все остальное в духе "ну мы там можем количество подписчиков регулировать и тем самым куда-то масштабироваться" - это свойство асинхронного взаимодействия, а не jms, amqp и прочих стремных аббревиатур, единственное что здесь еще играет хоть какую-то существенную роль - это возможность персистентных соединений, а заявления в духе: вообще ни в какие ворота: вот CometD вполне себе работает через HTTP, вообщем не кафкой единой.

Ну так к чему это все... ACK в очередях предназначен для того, чтобы пометить что сообщение было как-то обработано, отправителю от этого ACK не тепло, ни холодно

ну очевидно: весь контекст сериализовывать, а потом рассказывать про low coupling

Давайте так: я уверен на 100%, что ACK - это фишка консумера, а не продюсера, если вы так уверены, что при ACK что-то прилетает продюсеру (интересен сам механизм доставки сообщений продюсеру, если он ничего не слушает ), то можете привести в подтверждение правоты либо ссылку на документацию, либо на реализацию.
исправляю:

в мессаджинге тоже возможно синхронное взаимодействие через жопу .

как я уже пояснял другому оратору ( 22197194 ) вы также не неправильно понимаете слово "работает": ваше "вероятно это кому то нужно" возникает когда горе-архитекторы впаривают заказчику без должной проработки откровенную дичь, а потом пытаются мужественно преодолевать трудности:
- в Spring Integration (в Apache Camel тоже) оно есть просто потому, что это реализация EIP
- в EIP эту модель взаимодействия описали просто потому что она существует в JMS
- в JMS она появилась потому что на момент создания спецификации существовали вендорские реализации с поддержкой функциональности:Java™ Message ServiceJMS provides the JMSReplyTo message header field for specifying the
Destination where a reply to a message should be sent. The JMSCorrelationID
header field of the reply can be used to reference the original request. See
Section 3.4, “Message Header Fields” for more information.

In addition, JMS provides a facility for creating temporary queues and topics
that can be used as a unique destination for replies.

There are many styles of request/reply supported by enterprise messaging
products. From simple ‘one message request yields a one message reply’ to
‘one message request yields streams of messages from multiple respondents’.
Rather than architect a specific JMS request/reply abstraction, JMS provides
the basic facilities on which many can be built.

For convenience, JMS defines request/reply helper classes (classes written
using JMS) for both the PTP and Pub/Sub domains that implement a basic
form of request/reply. JMS providers and clients may provide more specialized
implementations. - а в вендорских реализациях оно было потому что иначе без этого невозможно было впарить клиенту

только какое отношение request/reply имеет к микросервисам? Адепты микросервисов топят за некий призрачный loose coupling, и при этом втихую реализуют RPC через жопу и умалчивают что это не что иное как temporal coupling, нарушая свои же собственные парадигмы. Зачем все это? У меня короткие идемпотентные запросы, результат которых нужен сейчас, а не когда кто-то там решит его обработать.

Ну просвящайтесь чтоли:
Messaging shouldn’t be used for queries
Messaging anti-patterns in event-driven architecture
When is an event not an event?

Ну вы определитесь кто на ком стоял: request/reply - это фишка JMS, которая прямо в спецификации описана, если мы принимаем за истину, что JMS проектировали умные люди, то посмотрев на кафку, мы заметим, что там "в коробке" этого нет , исходя из этого можно предположить что кафку писали бомжи... или таки просто не стоит предлагать использовать неподходящий паттерн там где это не нужно?