Welcome to API hell

I hate working with other people APIs. I love the concept of exposing your data, but implementation, most of the time, sucks.

There’s something pretty much fucked up in making your own business relying on someone else’s API, even when you’re paying for it.

Building a bug free software is hard enough when you control every single component. It’s becomes even harder when you count on someone else to bring bug free software.

I don’t mean APIs are fucked up. APIs are cool in many ways. They allow you to interact with a 3rd party service, build an ecosystem around your application, and they save lots of time and money, in theory.

IT security addresses 3 concerns that APIs enlighten a really practical way:

  • Data confidentiality. Data should not be accessible by someone who should not access them. Private messages on Twitter or medical information, whatever their nature, data confidentiality is content agnostic.
  • Data integrity. Data should not be modified, hence read only VS read write access, plus the need of strong encryption between the client and server.
  • Data availability. Data should always be accessible whatever the case. A fail whale is not an option.

That last point is always bugging me as I sign up for a service providing an API access. Do I pay to be able to access the data, or for the data I’m accessing? In the first case, any way to access the data can be considered as providing the service I’m paying for.

There is more. APIs are not meant to be static. They evolve and sometimes break. API development best practices state 2 important rules:

  1. Version your API so applications accessing version x won’t break when you release x + 1.
  2. Deprecate as much as you want, but never break the existing.

In the past 3 months, I had to face 2 critical regressions in EC2 API.

There was a change in the AMI generation so the instances don’t automatically reboot when triggering the image build. The consequence is, most of the time, an inconsistent filesystem. As that one is silent, we did not notice it until we deployed out of order virtual machines in production.

We had to rollback and it took a few hours to figure out why it was broken and how this happened could happen since we did not change anything on our side. Fortunately, upgrading [Boto] did the trick, but we lost almost a day.

The first one was with assigning a block device to an instance when creating a launch configuration. It happened the day AWS released their SSD backed EBS. The answer from Amazon support was the following:

Yeah, we admit we fucked the API up, but don’t count on us to fix that anytime soon. Here’s a workaround that works with our Java CLI tools instead.

I guess it’s a nice way to tell me welcome to API hell!

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: