1

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
DowNSERP
  • 23
  • 3

2 Answers2

0

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

Artem Bilan
  • 113,505
  • 11
  • 91
  • 118
  • I think I understand how you mean but it is unfortunately a requirement that the two applications (the client - note that in the future there will be more than one clients, and the server with the inbound http flow) have to communicate over HTTP and they will run on different machines etc. – DowNSERP Jun 03 '21 at 16:31
  • I added some emphasis to the part saying that I need to use HTTP. Sorry, I don't understand the part about `localhost` because I mentioned that they (the client and the server) will run on different machines. I tried to detail what I meant by the imaginary construct called "apiDefinition" - my question is whether there is a way to express something like that and share the definition of the API that way between the client and the server code. – DowNSERP Jun 03 '21 at 17:06
  • Something similar is a Swagger file and code generation. Client and server code can be generated from the same API definition (in Swagger's case, a descriptor file). I am asking whether something like that exists for Spring Integration with HTTP either in the form of DSL, descriptor file, XML, or anything. – DowNSERP Jun 03 '21 at 17:07
  • So, what you are talking about is something like REST contract. Well, no. There is no something like code generation for Spring Integration. It is not a messaging-friendly. Sounds more like an RPC which cannot be too platform and API independent. On the other hand, Spring Integration has a generic Service Activator pattern impl, where you can use the mentioned Swagger generated stubs. – Artem Bilan Jun 03 '21 at 17:35
  • Thank you, the "generic Service Activator pattern impl" sounds good, could you please link me some code example if possible? – DowNSERP Jun 03 '21 at 19:13
  • Here you are: https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints.html#service-activator ! The point is just about calling some Java method from a service activator endpoint. See theory in the EIP Book: https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingAdapter.html – Artem Bilan Jun 03 '21 at 19:24
0

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.

Darrel Holt
  • 870
  • 1
  • 15
  • 39