Original Article: Architecting Multiple API Integrations
Overview
The complexities of integrating with third-party API’s can quickly multiply due to the rapid proliferation of competing API’s and standards. This significantly increases development, testing, and maintenance time/costs, but can be mitigated against by integrating with a middleware API that delegates to various third-party services.
The Proliferation Problem
While the rapid growth and adoption of webservice API’s and standards have been a real boon for the software industry, nothing comes without a cost. The cost, in this case, is a rapidly expanding and constantly evolving frontier in which there are often multiple offerings in any given domain, several of which often proving desirable candidates for integration.
As we saw in the previous articles What is API Integration, and
API Integration Basics, the answer to “How do I do X or integrate with Y?” is almost always “There’s an API for that”. However in many cases, the answer actually comes back more along the lines of “There’s 5 or 6 different API’s for that, which one do you want to use?”, and then as an app developer or POS integrator you have to choose. What’s the one API you’re going to integrate with? Or do you invest the time and effort that it takes it to integrate with several of them? And the extra time it takes to maintain those integrations?
API Integration Basics, the answer to “How do I do X or integrate with Y?” is almost always “There’s an API for that”. However in many cases, the answer actually comes back more along the lines of “There’s 5 or 6 different API’s for that, which one do you want to use?”, and then as an app developer or POS integrator you have to choose. What’s the one API you’re going to integrate with? Or do you invest the time and effort that it takes it to integrate with several of them? And the extra time it takes to maintain those integrations?
For Example
Say you’re creating a solution that allows a user to browse and purchase digital music from within your application. Amazon offers an API that will let you do exactly that. And so does Apple. And so do Bandcamp, Spotify, Murfie, and others. Each one may offer some catalog items that the others don’t. And wouldn’t it be great if your solution could seamlessly integrate with all of them?
Certainly, it would! But the cost of doing so is very high. Although each API ostensibly performs the same function, each one is independent and structured differently from the others. Where one codepath should logically suffice, you’re going to need five. Each one is going to have its own credentials, its own authentication strategies, its own API quotas and limits, and its own quirks that need to be smoothed over if you want your users to have a seamless experience. And once you’re done you’re going to have to track changes to each API and ensure your app is updated and maintained accordingly.
Thus the proliferation problem should be obvious. Unless you’ve got the development might of a Google, Apple, Amazon, or Microsoft there are more API’s out there than you can realistically integrate with. You’ve either got to settle for an integration with a single API and dealing with frustrated users upset that they can’t find any content from ‘API B’ within your solution, or else dive in and try to support as many parallel API’s as you think you can get away with.
A Better Solution
Imagine if instead of talking to a bunch of related API’s individually your application or POS system could talk to a single service that internally handled communication with each of those related API’s and then just shipped you the result. It might look something like this:
We’ve added a “middleware” layer that sits between your solution and the rest of the world. And now instead of talking to a whole bunch of completely different and differently-structured API’s your solution only needs to integrate with one API; the middleware’s. It’s connecting to the same amount of information, if not more, however, the complexity on the application/POS side has been drastically reduced. This carries with it a corresponding reduction in development, testing, and maintenance effort; or in other words, time and money.
You’ll notice that the middleware has a proper name. It’s called Doshii. Doshii provides API integration, management, and aggregation as a service. This frees up your time to focus on your actual product and saves you from having to worry about whether to integrate with one service or several and from the complexity and overhead associated with the latter option. And of course, it’s all accomplished through an API.
Strangely enough, it seems that the answer to the proliferation problem is yet again “There’s an API for that”. By leveraging a middleware API such as Doshii, your solution can gain the benefits of multiple parallel API integrations without any of the added development costs. There’s no longer a need to implement and maintain multiple codepaths that all accomplish the same logical task. And dealing with changes, updates, and maintenance as all of those API’s evolve? Well that all becomes Doshii’s problem; you don’t have to worry about it!
By placing a ‘middleware’ webservice between your solution and the webservices that it ultimately wants to communicate with, multiple integrations can be replaced with a single implementation and API proliferation becomes much less of an issue. The power and flexibility that this kind of solution provides are difficult to overstate.
Thanks for this informations about API Integration.
ReplyDelete