Spring Integration code sharing between outbound/inbound

Question

Imagine you have an application (let's call it B) with an inbound HTTP interface (using HTTP is a requirement). You will call it from several different other applications in the future but at the moment you only want to develop a single client (let's call it A). So in A, there is an outbound HTTP gateway:

A (outbound gateway) ---[HTTP]---> (inbound gateway) B

Is it possible to share code e.g. the HTTP API definition like path (for example "/hello"), method (GET, POST, PUT...), maybe parameters/their type/response between these two apps? If yes, how?

I would like to use the Java DSL but I see that Http.inboundGateway("..") and Http.outboundGateway("..") are totally different (e.g. the type) so I am not sure. Ideally I could have something like:

  @Bean
  public IntegrationFlow inbound() {
    return IntegrationFlows.from(apiDefinition)...
                           .get();
    ...
    ...

  @Bean
  public IntegrationFlow outbound() {
    return IntegrationFlows.from(somehwere)...
                           .handle(with(apiDefinition))
                           .get();

Api Definition can be imagined like the following (pseudocode):

apiDefinition =
  method: GET
  path:   /items/{id}
  parameters:
    id: string
  response: item

Answer 1

Well, it sounds more like you don't want to do a call over HTTP in that your client and be able to get directly to the business logic. In this case the best thing what exist in Spring Integration is a MessageChannel abstraction. So, no matter what is an input endpoint (HTTP, JMS, Apache Kafka, JDBC etc.), you always can point them to the same channel where some service activator is a subscriber to that channel to perform desired business logic.

So, to by pass an HTTP call in your current client, you just need to introduce a MessageChannel as an input for some IntegationFlow with business logic. The HTTP inbound flow would use a .channel(myBusinessLogicChannel). And your outbound would do the same in its logic. This way you would have two clients for the same API: one over HTTP and another one direct.

I also can recommend to investigate what is a Messaging Gateway as an alternative to design a high level API with minor messaging interaction from the client perspective. The outcome would be the same: HTTP inbound flow could call that gateway. And it can be used in the other end-user code to be called directly.

See more docs about channels and gateways:

https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints.html#gateway

Answer 2

I would run A on Spring Boot. Just a regular MVC approach. It allows it to be scalable if you want to add a GUI to have a frontend to it in the future even though right now you just want an API. and then you can just setup your endpoints to return whatever data you'd like as a SuccessResponse containing a HashMap or whatever data structure you'd like to be Serialized and passed back as a HTTP response. You can look at some of my questions about spring boot if you want a start on how it looks. There's also the Spring Boot documentation from Baeldung here. There is also a spring boot project starter here and it lets you setup the whole project including dependencies, build automation tools, etc.