@malsowayegh I think you are in the right place where you integrate Interface or contracts in your code for these services. The challenge you are facing is grouping the similar functions they have like configuration, subscription, and unsubscribe methods.
Backend Integrating with large 3rd party API that could change in the future
Hello there,
before I start, I'm just trying to get some general info and if possible some resources that can help me with my problem.
Basically I want to Integrate my service with a Credit Card Issuer. They have a very large API with many API Resources. I don't want to hard code my service to this Card Issuer since in the future we will 100% partner with another Issuer alongside with current one or even totally replace it.
I was looking at some example over the internet and I see that they follow serviceInterface & AbstractService for all of their 3rd party integrations with an interface that have simple call function as a contract.
My issue that I have a really specific thing that the Issuer do with lots & lots of endpoints.
As you can see I'm confused and everything I wrote is scattered allover. What I really need is some resource to read about this issue from a software design pov so I can work my way through this problem.
@malsowayegh You need to define interfaces for the operations your application intends to do, and the parameters and responses you’re expecting. Then build a class for the particular processor that adheres to this interface.
If you define and rely on only the interface in your application code, then that means you can write an alternatively implementation in the future, bind that to your interface instead, and your application will continue to work without changing any code—because it’ll be relying on an interface and not a specific implementation.
Please or to participate in this conversation.