Eran Galperin is the CTO of Binpress, a marketplace for commercial open-source projects. As part of its goal to evangelize the use open-source professionally in business and enterprise, Binpress also hosts a large amount of API wrappers, libraries and SDKs.
We live in the age of the API. Almost every self-respecting web service today provides some kind of programmatic access to its data and/or facilities. APIs range from location-based data to online payment processing and everything in between.
Not all APIs are created equal though. For any specific task you can likely find multiple competing APIs that use different approaches and provide varying levels of documentation and support – all of which you should take into consideration when picking which API to use.
Picking the wrong API provider could be a major time-sink or worse – it can create vendor lock-in that is hard to break out of (think payments APIs). In some cases you would be marrying your application to the capabilities of a specific API – so making the right decision is critical.
When comparing APIs and trying to determine which is right for you, there are several things to consider:
Even if you go through the entire checklist you still must prepare for the fact that APIs and your product will evolve and change in ways you can’t predict. How do you interface with an API today in a way that won’t cripple your product tomorrow?
To protect against change, you should always have a layer of indirection for interacting with an API. If you are handling payment data then you should pass off your generic payment information (customer and address details, payment method, charge amount and description, etc.) to an API wrapper class that can deal with it internally and make the call to the API provider. In the same manner, your application code should not deal directly with API responses, but with normalized data returned by the API wrapper.
In cases where you need to switch providers or switch to another API within the same provider, having a layer of indirection and some forward thinking could save you A LOT of time and anguish.
When using a library or SDK provided by the API provider or community, it is my rule of thumb to always have my own abstraction in front of it, as those libraries typically talk in the language of the API (i.e, specific API flows or methods). Having this additional layer of indirection in front of the API library should lead to reduced switching costs and simpler interfaces to work against.
Picking an API can be a major commitment depending on the scope of integration and the services it provides. At the same time, many APIs give us access to data and processes that are otherwise not accessible without a huge time investment and capital.
As Uncle Ben once said, “with great power comes great responsibility” – do your due research ahead of time and use indirection to interact with the API to minimize your risk while harnessing the power offered to you by API providers. See you in the cloud.