2

I have 5 interfaces in an API component, which in its turn call an external 3d party solution provider (REST).

The goal is to make this component universal, and under the hood support multiple service providers from the same industry for example, loyalty management. In other words the API component is a facade / gateway above a particular 3d party solution provider.

My question: is this even feasible and right goal to cover different service providers with the single API?

My concerns are following:

  • The different solution providers provide different set of interfaces and functionality behind them. No one can guarantee that the interfaces added for the first provider will be supported later by another one. Because there is no standard or any industrial agreement on that.

  • On other hand, no one can guarantee that the interfaces which were added for the first solution provider to fulfil needs of one project will be demanded by other projects.

  • Simply the signature of each interface can be different from provider to provider.

All-in-all, such uncertainty is kind of natural for the cases, where I rely neither on my implementation or other implementations based on industrial standards/requirements.

1
  • You may choose to model your API based on your businesses needs - since its likely that some compromises may be needed from your needs to the various service providers, your API becomes of a mapping of: needs to implementation.
    – DavidT
    Sep 30, 2023 at 19:29

4 Answers 4

1

My question: is this even feasible and right goal to cover different service providers with the single API?

This question is not answerable for us, because it depends very much on your actual use case.

Providing a universal loyalty management API is feasible if the functions/features you need to offer to your users are also provided by each of the underlying providers that you abstract over. Depending on the differences in how those features are offered in all the various APIs (and how you intend to offer them to your users), it can be more or less work to create an adaptation layer between your API and the API of the underlying service providers.

If this is the right goal for your component, we cannot decide. That is completely up to you and your stakeholders.

1
  • Thank you very much for your answer. Sure, almost always it is a trade-off. In most cases the decision completely depends on particular examples. Sep 28, 2023 at 10:57
2

no one can guarantee that the interfaces which were added for the first solution provider to fulfil needs of one project will be demanded by other projects.

So in other words, you are asking if it is worth to build a solution if you don't know if that solution will be ever needed by anyone?

Well, if you do this just for fun or for educational purporses, this might be worth the effort. But in my experience, for real-world software, one will usually only be successful if one can satisfy someone's need. And as long as I don't know anyone who has a real demand for a certain component, I would invest my time into more promising projects.

TLDR; I had a lot more succcess in my career in starting with a problem and creating solutions for it, than by creating a solution and then looking for a problem which fits to the solution.

1
  • 1
    The TLDR hits the nail on the head. If there's demand, and someone is willing to pay you if you provide a solution, working on a problem may be worthwhile. Otherwise, consider it a hobby project on which you can spend your spare time. Sep 28, 2023 at 15:25
1

Based on your concerns, you may be a little confused about how an Adaptor component fits into an architecture.

The different solution providers provide different set of interfaces and functionality behind them. No one can guarantee that the interfaces added for the first provider will be supported later by another one.

The point of an adaptor is not being able to switch from one provider to another without changing the adaptor implementation. The goal is to create an interface used by your adaptor's clients that doesn't change unless requirements change. The idea is to minimize the impact of such changes on the larger architecture. The adaptor's implementation (not its interface) should be expected to need to change, otherwise it has little purpose.

The fact that different providers might have different APIs is the main reason to implement an adaptor, not a contra-indication.

On other hand, no one can guarantee that the interfaces which were added for the first solution provider to fulfil needs of one project will be demanded by other projects.

If an alternate 3rd-party provider cannot support your requirements, why would you use that provider? The requirements should drive the solution. Changing your requirements based on what a 3rd-party provides is (IMO) a backwards way to think about solution design.

In fact, building an adaptor can help you determine if a given 3rd-party solution meets your requirements. Once you have built an adaptor whose interface is specific to your requirements, i.e., it provides the necessary operations and nothing more, evaluating a 3rd-party's solution becomes an exercise simply determining whether you can implement your adapter against that 3rd-party. If you can't, it doesn't support your requirements.

Simply the signature of each interface can be different from provider to provider.

This is the main reason why adapters are introduced. If you could guarantee they provider interfaces will always be the same, then the case for building an adaptor layer is much weaker.

In a nutshell, all these are reasons you would potentially create an adaptor layer/component, but you seem to think they are reasons not to do it. As to whether you should do this, that's a harder question. As an analogy, let's say you need to make a workbench. You could create a standard workbench where everything is permanently glued together, or with more effort and planning you could create a 'knock-down' workbench which can be easily disassembled and moved. Which should you build? The answer is that if you don't ever need to disassemble it, you probably shouldn't bother with the extra work. But if you do find you need to move it often, you'll might be better off (in the long-run) making the knock-down bench.

It can be very difficult to make such predictions and it's probably not something you want to do in a vacuum. If it's clear that there is a desire to be able to change providers with minimal switching-costs, that might be enough reason to do this alone, even if you never actually change providers. The reason is that a credible threat of leaving one provider can be an advantage in negotiations. If the provider knows moving to another will come at a high cost to your organization, they don't need to try as hard to keep your business. It's also my experience that 3rd-parties will change their implementations drastically over time.

If you decide to build an adaptor, be careful about duplicating the APIs and features of your first provider. Specifically: only implement the features you actually use on your API. I would even try to ignore the design of the 3rd-party's APIs, at least initially. Your goal is to create an API designed around your organization's needs, not the 3rd-party's.

0

Design of API which is based on third-party implementations

The design of your API should be based on your needs.

The fact that you plan to use third-party implementations is, well, an implementation detail. Those things do not need to, and really shouldn't, be visible in the API that abstracts those details. The API fulfills need X. How it does X is not important to things that need X. Make X visible. Hide the stuff behind it.

Design that way and not only will the API be simpler, it will be something that can endure even when those third-parties disappear on you. Just go find something(s) else that can provide X. Feel free to ignore the Y and Z that they provide because our need is X.

This is the heart and soul of Abstraction and the Interface Segregation Principle. They aren't just for objects.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.