Use of internal interface around paid APIs

Question

Note: I'm new to using paid APIs (like Stripe, GPT-3, Twilio, ...).

When you are using a paid 3rd-party API, you are essentially betting on them keeping reasonable prices in the future, right? So in case you'd want to switch the API provider, potentially the work to switch could be huge if their endpoint design is different and they use other naming conventions.

Wouldn't it make sense then to wrap such APIs in an internal interface, so that you don't rely on the vendor itself?

I haven't seen much about that, or didn't know what to search for to find relevant results. Could you point me to relevant sources if I am missing something?

Answer 1

Have a look to the facade pattern:

https://refactoring.guru/design-patterns/facade

Is just for that:

Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.

Answer 2

Third party APIs usually have a very broad purpose, so it's often useful to create a wrapper to simplify down to your exact use case, and to add things like caching and rate limiting, and adapt the interface better to your language and style choices.

In my experience however, trying to make a wrapper for the sole purpose of potentially swapping out a different implementation in the future rarely works out. That's because it's much more common to switch back ends based on features than price changes, and those features usually require significant wrapper interface changes.

For example, the migration I'm currently working on requires a shift from a synchronous interface to a lazy asynchronous interface. That's not something that was anticipated when the wrapper was first written. In general, it's really difficult to anticipate future interface requirements like that. Facades are therefore most useful if you already frequently switch back ends now, like different APIs for different deployments, etc.