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?


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.