Building a service around external APIs
I am thinking about building a service around some other company APIs. However, prior of diving into some code, I would like to evaluate all the strategic aspects of such a "one way partnership".
Some aspects I thought about:
- My service uptime is totally dependent on the third party API, this means that I won't be able to provide a best service I might want to.
- As far as I know, APIs are subject to rapid changes, so basically I can find myself updating my code more than I intended to (or even find myself running against the clock).
Can someone share, from his experience, some thoughts on this subject? What are the main things I should take into consideration? Are there some services which can help me with these concerns?
-
Joel called this something like - "picking nickels up from in front of a steamroller" if I recall correctly. It can be a successful thing to do - but there is risk as you note. – Tim J 13 years ago
-
Consider the fact that you can really get burned. Didn't Twillio one day just decide they didn't support Europe (6 months back??) Google App Engine suddenly increases prices. Twitter just decideds to cut off access to some data. Basically your business exists at their whim... – Doug N 13 years ago
1 Answer
Impact of change.
It would depend on your archetecture, the abstractions you place between "your world and theirs".
If the form changes, but the function remains the same (ie, facebook still has a social graph but you use SQL OR XML services OR Rest/JSON OR the next big magic thing).
If you can manage this key issue in your design, then YES you will be rewriting your integration piece with them several times over BUT with the right design it shouldn't impact 10% of your application (which is the I/O piece).
Number of "suppliers" Is there only 1 "supplier" or could you have several "eg News feed from Twitter AND Facebook"
If your aggragating several services together (say, all freight carriers into one API for requesting and tracking freight OR Extracting banking summary data securely OR whatever)
While Joels, nickels infront of the steamroller can be accurate ...
- For well established businesses this is very important to be able to integrate into a stream ... if you have done it, they don't have to.
- For single sources like facebook or Twitter, they can either compete against you or buy you, make it obvious which choice they should make by hard function to perfect, marketshare takes too long to aquire on your own, your know the space better than them ... simply easier to buy yours and your on a winner.
- If you tie several APIs together like ifttt then an create something bigger then your both cementing your suppliers position and creating your own place in the market.
From the supplier who is also paying you for the transaction then you may be in trouble, their plans change, your out ... if your volumes high enough then make hay while the sun shines.
From the general public paying for your service. This is better because your then if you get traction your a viable buyout target.
From advertising. If you can get a high enough volume, or can segment your market well for the advertiser then your in luck.
From a group of businesses. If a range of busineses are paying for you to "provide your piece of the puzzle", provided it isn't their core business they will usually be happy to pay you to deal with it IF your cheaper/safer than them doing it.
