In our current architecture, a user has multiple ways they can change an address (as an example). They can do it through an online portal, through our core processor directly, or via a number of apps that talk to the core processor. I want to design a solution that has one place for all of those users to funnel to, and one place for the business logic, instead of half a dozen. I'm writing a wrapper API (RESTful) that abstracts our core processor's SOAP API for ease of use. The reason for the abstraction is because we use a primitive proprietary programming language that doesn't generate XML as easily as it can simply call out to a URL.

I'm evaluating third-party proxy layers such as Mulesoft for this, but I'm also researching solutions that would allow for business logic to be placed into the RESTful API before it calls out to the core processor. We also want to plan for the occurrence that the core processor may eventually change, and the SOAP API could be replaced with something else. What design pattern (if any) would I use to decouple the API interface from the underlying SOAP API and core processor so that if we need to switch the backing API to a completely different API that provides similar data and maybe uses a different transport mechanism, the outer API wouldn't have to change?

I believe it would either be the adapter pattern or the bridge pattern, but I'm not very experienced in SOLID or design patterns and am not sure which would apply (if any). I know the bridge pattern is for up front design, while the adapter pattern is after the fact. It seems like both to me.

Or is this just inversion of control at work?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.