The Danger of Third Party APIs

Generally speaking, the majority of the work that I do with third party APIs is done so in the context of WordPress, but the truth is that what I’m about to say is subject to whatever platform you’re work with – be it .NET, Rails, COBOL, or whatever you or your dad maybe using :).

But a feature in Standard recently quit working because of an underlying change in a third party API. Now, to our credit, we normally do a good job with following blogs and release notes when an API is going to change.

In this case, there was no documentation on any of this – something just stopped working, so we needed to dig in and fix it. The fix is under testing and will be released later, but the point that I’m trying to make is that there is always a danger in working with third party APIs.

Third Party APIs: A Band-Aid?

I had a great conversation with a friend this morning about constantly having to work with third party APIs.

I said:

I’m getting the markup of the user, parsing out the [information], and storing that as transient data.

He mentioned:

I am up for experimenting, but I think here is still risk involved. What if [the service] is down? What if they change the markup?

A valid point, isn’t it?

And I know that not working with the direct API is a pain, but when it requires that you register an application, submit to things like rate limiting, and then distribute your work to a wide audience, then there has to be another way.

I mean, all we’re trying to do is read-data. That’s it.

We’re not trying to push any data out, we’re not trying to access any special information – we’re simply reading information. To that end, I have a hard time believing that authentication should be required when the information is available in a web browser and, thus, in markup.

And, going a step further, the markup can be parsed using a regular expression.

But working with third party APIs still leaves one question

Is Working with Third Party APIs a Band-Aid?

band-aid

In short – and this is based purely on my experience – it depends:

  • If the service provider does an excellent job of communicating changes that are coming, gives you time to update your work against the new API, and gives you hard end-dates, then no, I don’t believe it’s a band-aid.
  • On the other hand, if the service provider does a fair job of giving you updates but still changes the API without prior notice, then it might as well be a band-aid because you never know when you’re subjected to when it will happen again. Thus, you’re kind of left with just chasing solutions.

Obviously, we all prefer the former case, but it doesn’t always happen.

What’s a Developer To Do?

Follow blogs, keep your software updated as best as possible, but accept the fact that third party APIs and service providers may simply pull the rug out from under us.

Is it worth getting frustrated about?

I dunno – on one hand, sure; however, if it’s something that tends to happen in our culture, I see it just as a matter of acceptance. Apologize to the customers – place no blame on anyone as that’s low class – put a fix in place as soon as possible (and be communicative about it), then roll it out.

For the most part, no, they aren’t band-aids. There are a few out there (as Norcross has pointed out in the comments), but you have to take those in stride.

9 Replies to “The Danger of Third Party APIs”

  1. Hard to say. If given the choice between an “official” API and 3rd party, I’ll go official every time. but occasionally there are times where I need data and 3rd party is the only way to get it. I usually include some verbiage about the fact that its unofficial and could change / cease at any time.

    1. Well, I confunded the terms. What I meant by “Third-Party API” is an official API by a third-party service.

      But yes: You’re right on with this:

      I usually include some verbiage about the fact that its unofficial and could change / cease at any time.

    1. Exactly – and that’s the thing. It’s about trust.

      Personally, I just expect things to work as documentation promises, but if it breaks I think we have to own the responsibility that we’ve created on the dependency.

      Let customers know, fix, and move on.

  2. If you don’t like 3rd party APIs, roll your own ;)

    There’s no actual reason for this post. You use an API or scrape something because you can’t produce that yourself. So, whatever tune the 3rd party sings, you need to dance accordingly or start your own band.

    You can’t liberate yourself from APIs unless you can replicate their functionality. But you can be smart and minimize damage if things go awry.

    PS: No serious non-free API provider changes API without notice (Twitter aside) and they usually maintain backwards compatibility. Unless you scrape a site and markup format changes… and you ‘re-train’ your scraper, which comes with the territory.

    1. There’s no actual reason for this post. You use an API or scrape something because you can’t produce that yourself. So, whatever tune the 3rd party sings, you need to dance accordingly or start your own band.

      Though I agree that we need to “dance accordingly,” the purpose of the post is simply to share that there are challenges that come with using third-party APIs.

      Sometimes, they have and do change their APIs without maintaining backwards compatibility, and without warning.

      But you can be smart and minimize damage if things go awry.

      Definitely. And you always should. Nothing should blow up if an API call fails. Instead, it should should fail gracefully and generate a log file or some type of indicator that can be reported to the developer(s) so they know where the fault was.

      No serious non-free API provider changes API without notice (Twitter aside) and they usually maintain backwards compatibility.

      A non-free API provider should provide notice, but Twitter is free so they are subject to do whatever they will do (as are several other services) as far as I’m concerned. I’m not saying that’s an good thing – after all, when you’re a service that big and you’re providing a platform for developers (and I use that phrase loosely), then you’d expect some kind of notification.

      But either way, I agree that “non-free” can and will make changes and potentially without notice, but not all third-party APIs are non-free, and we’re living on a social web full of free, third-party, self-proclaimed developer-friendly APIs.

      Unless you scrape a site and markup format changes… and you ‘re-train’ your scraper, which comes with the territory.

      Sure. I don’t think anyone would argue that.

    2. TRUE!

      […] we’re living on a social web full of free, third-party, self-proclaimed developer-friendly APIs.

      No such thing :) Sooner or later, they all go for the throat monetization. And you can understand that as there’s (at least) hardware costs involved in APIs that needs to scale. As the saying goes: If You’re Not Paying for It; You’re the Product.

      The real risk is relying on free APIs, not APIs in general. I’m really curious how all the free APIs/services of today will act… tomorrow.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.