Rock-solid RESTful APIs and the Testing Backblob

I’ll be presenting “Testing Twofer: how to Release Rock-solid RESTful APIs and Ice the Testing Backblob,” on Tuesday, September 9, courtesy of SQUAD – the Software Quality Association of Denver.

REST APIs are a key enabling technology for the cloud. Mobile applications, service-oriented architecture, and the Internet of Things depend on reliable and usable REST APIs. Unlike browser, native, and mobile apps, REST APIs can only be tested with software that drives the APIs. Unlike developer-centric hand-coded unit testing, adequate testing of REST APIs is truly well-suited to advanced automated testing.

As most web service applications are developed following an Agile process, effective testing must also avoid the testing backblob, in which work to maintain hand-coded BDD-style test suites exceeds available time after several sprints.

This talk will present a methodology for developing and testing REST APIs using a model-based automation and explain how this has the beneficial side-effect of shrinking the testing backblob.

The testing backblob is my riff on out-of-control Agile testing backlogs. I’m seeing this situation quite often as Agile development teams become swamped with a test maintenance problem that doesn’t have any attractive solutions.

I’ll explain some new strategies I’ve developed for Spec Explorer to test all aspects of any REST API, including functionality, security, and performance.

To register for the meetup, go to


Buggy APIs are Eating the World

Try searching “Buggy API” on Google or Bing. When I wrote this post, I got 16,600 and 2,660 hits, respectively. For some entertaining commentary on the offenders, try it on Twitter.

This would be funny if it wasn’t so pathetic and completely unnecessary.

In this, I see results of the “fail fast” mantra, superficial testing, the presumption that “I coded it, therefore it’s good,” and hostility to documentation as a badge of honor. These aren’t new software development problems, but the way they rapidly impact a large user base is a novel side-effect of present-day technology.

Marc Andressen famously claimed that “Software is Eating the World.” From the level of API quality that Google, Bing, and Twitter report, it looks like more has been bitten off than can be chewed.

What does it take to develop a robust and usable API? Technical tricks matter, but they can’t save a bad design. Design theory and general requirements for correctness were established a long time ago with Abstract Data Types and Meyer’s Design by Contract. Web APIs must also support a conversation between sender and receiver—a protocol. Getting the rules right for all possible conservations is a hard design problem. Security and performance flaws can be found and corrected, but not with happy path testing. Putting all this together takes a certain kind of artistry, much the same way that good music is more than just notes.

But even if you do all that, you’re not done, unless you don’t care about garnering users and growing usage. Code can’t tell the whole story. I learned this firsthand reading and critiquing thousands of pages of API documentation released through the Microsoft Open Specifications process. You have to explain how your API works so that any third party with basic programming skills can use it with minimal effort. I haven’t yet analyzed the buggy API complaints to see how many are about documentation, but it’s clear this is a common pain point.

So, releasing robust and usable APIs isn’t impossible, but it isn’t trivial. It takes thinking through and validating a design. It takes thorough testing of allowed and unallowed usage and data conditions. And it takes complete, consistent, and accurate documentation.

If all this seems like a lot, well, it is—especially when this kind of work isn’t your strong suit. That’s why we’re offering Advanced API Verification.