Heal Your Church WebSite


Teaching, rebuking, correcting & training in righteous web design.

Don’t get BOSS’d around by your 3rd party API

As the dust settles from last week’s “Micro-Hoo!” partnership announcement, developers around the globe are beginning beg the question “what about my needs?

Don't get BOSS'd around by your 3rd party APIs

Specifically, coders are now worried that Yahoo!’s surrender of their search engine to Microsoft also means abdication of BOSS – Yahoo!’s open ‘Build your Own Search Service’ web service.

If it turns out that the end of Yahoo as a search engine means the end of BOSS, then those developers who didn’t adhere to Spolky’s advice in chapter 35 of “Joel on Software” may be in for a rude awakening. In other words, those who built core business functionality directly into Yahoo!’s third party API may now find themselves scrambling to implement an alternative.

Even those developers who employed BOSS to provide non-core business functionality in their solutions may find themselves in for some sleepless nights if they directly integrated the API in to their code.

So what’s the lesson learned here?

Well in a world of Web 2.0, it’s unreasonable and potentially uncompetitive to completely exclude the wealth of external data sources now available via streams such as SOAP, RSS, XML-RPC and REST.

That said, here is a semi-definitive list of actions we we can developers can take to mitigate the risk such integrations introduce.

  1. “If it’s a core business function – do it yourself, no matter what.” This come straight out of Spolsky who enumerates a host of issues that can beset businesses who ignore this tenet; to which I’ll add that telling clients it’s someone else’s fault they can’t get to a needed feature quickly makes that paying client think perhaps they need to cut out the middle man.
  2. Carefully choose which functionality of a 3rd party API to integrate. If it can’t be readily obtained from competing third parties then you may find yourself having to re-invent that wheel in one night – or worse – being held hostage by said vendor when they change their terms of service.
  3. Always build a wrapper methods to 3rd party APIs. This way if and when the time comes to switch to an alternative API offering similar functionality, all you need change is the wrapper to the service, and not the hundreds of calls within your application to the service.

I’m sure there are other actions we can take, which is your queue to provide feedback for any other techniques and/or approaches to not getting BOSS’d around by your 3rd party API! Don’t be shy.

I’m also wondering just how many of us got caught a bit code-short when Zondervan announced its purchase of BibleGateway.com? Any stories out there?

Meanwhile, here are some additional links related to the topic above for your reading pleasure:

One Comment

  1. Another good practice would be to code a simple fall-back or alternative content. That way, whether or not the 3rd party is bought out or times out or fails for whatever reason, you can rest easy at least for a few days knowing that even though all the functionality may not be there, your site isn’t broken, and you have a little time before is absolutely must get fixed.