APIs – When a Misconception Becomes the Truth

When work started on API Fortress the CTO hated the word API. He was adamant that the majority of what was called APIs were actually, in his words, “freaking web services!” Yet, API was the buzzword of the time and thus ‘API’ was used in the company name. This is a common dirty little secret in the tech industry. It is often easier to describe something using a commonly held misconception than trying to change what people think they know. Only a few years ago HTML5 was used to describe advanced web features that were actually Javascript.

This happened with APIs. For years APIs were internal to software. It was how a piece of a software could interact with another piece of the same software. A web service could be an API, but that meant it had to allow two pieces of software to work as one.

This confusion led to a gap in current testing theory. Testing pieces of software (a unit test) was considered enough, even though most unit tests only check the code up to where the web services are composed. The commonly held belief was that, “it worked fine up to here, why would it break when it goes beyond?”

Then something new arrived and changed things – microservices. It is a trend that forces APIs to actually work like a proper APIs. This new wrinkle now give us the ability to easily test internal parts of the software against a live environment. The new frontier of integration tests has begun.

An integration test can validate the final output of the entire system and all its intermediate steps. It can verify that every flow is working properly when combined with live data. We believe that everything is best explained in GIF or video form. A unit test confirms that the windows work individually. An integration test confirms the windows work properly after installation. See the difference?