I'm implementing a service that needs to call another service that calculates a result in a way I cannot know.
Let's say I have the following scenario: I have some place in my code, calling a HTTP request to a defined endpoint another service returning a defined result. Now, I mustn't dictate how the result will be calculated, however I can define the result output data type I'm expecting. I want to put emphasis on this, since otherwise I would just implement the calculation logic in my service.
I would then describe it to the user:
You need to provide an HTTP service, with this exact endpoint, receiving these exact parameters, delivering this exact result type, but how you calculate the result is your job. I just need the URL of your service.
Afterwards the user of my service would configure the URL to their HTTP service into my service, so that I can make a HTTP request to {url}/defined-endpoint
.
I couldn't think of another name but "service-injection" to describe this concept, since it has a resemblance to dependency injection, just that in code you don't provide an object instance, but a service that is called via http.
My question is: Is there a pattern for this concept or an alternative that more elegantly solves the general problem of outsourcing a calculation to another service?
CodePudding user response:
You are defining a contract of how the interface between your service and the other service. This means that as long as the contract is respected by both parties the integration and communication will succeed. Not sure if "service-injection" is a good terminology for this. You are not injecting something in your own service, you are simply delegating the calculation to another one, but you don't inject the logic of the service into your own. And that is good because then you have a good separation of concerns and loose coupling. As long as the contract is respected, both services can be changed in whatever way it is needed and the integration would still hold.
Is there a pattern for this concept or an alternative that more elegantly solves the general problem of outsourcing a calculation to another service?
This is just how things work in a micro-services ecosystem. You have multiple services exposing APIs that communicate with each other to provide as a whole a higher-order functionality.