Design pattern for wrapping multiple apis into single api

Question

I have 3 different libraries that provide depth data as well as gesture information. I need to wrap these libraries into a single simpler to use for user api. The apis I am trying to wrap provide a set of utilities as well as information that are not equal. The core data such as depth images or color images are provided but tracking can have different method or amount of information provided may differ. For example, one api provides a list of hands being detected and each hand has internally an orientation info(l/r). Another api provides l/r hand objects with NULL if not found and info if found.

I need to wrap these apis into a single api in the same language(c++) that allows user to have to write way less code to get the core functionalities. Is there a pattern that provides best-practices for such a task? Or any examples in industry that do something similar? I understand that single tight-knit apis are better than a large api, but for my current use-case, a large api makes sense, so I need to do that.

Answer 1

As others have said, the Façade pattern is an obvious way to go. To add to the answers thought, I'd like to say, you need to think carefully about the semantics of the API you are trying to wrap when creating the simpler Façade. Syntax is the easy part.

For example, your API may require an initialisation function followed by functions which actually do the bit you are interesting in, followed by a tear down before allowing a new init. If you abstract away the init part are you potentially adding unnecessary processing with every API call (init, process, tear-down) without the user knowing that they are doing so.

Obviously, my example is completely hypothetical, but it just goes to illustrate that you need to think carefully about how the API is simplified so unintended consequences are not introduced.

Answer 2

I think what you're looking for is the Facade pattern (https://en.wikipedia.org/wiki/Facade_pattern).

Basically, you create a friendly, front-facing API for your users/developers to call.
When the facade API is called, it translates the call into one or more calls to one or more of the "source" APIs, then passes the results (maybe with some more translation) back to the caller.

Essentially, it masks the complexity of the source APIs (and gives you an opportunity to standardize the request and response data, formats, etc.).

Answer 3

It seems a mix of Abstract Factory Pattern and Façade. You would have a common interface (abstract class) and families of concrete classes which implements the API for each provider. Through the factory, you could select which provider to use.