API development is often explained to newbies by way of food-related metaphors, and it’s not hard to see why. Working on an API project is very much akin to fine-tuning a recipe for a delicious new dish before its inclusion on the menu. In both cases, there’s a lot of prep work involved and a lot of testing that needs to be completed before the product’s debut.

And just as it is with the signature dish of a restaurant, the perfect recipe for a fully functional API can’t be thought up in one go. API designers have to do the tedious work of refining the product in disparate testing stages, and they often spend a lot of time repeating the motions of one stage before moving on to the next.

This is where we come to the issue of API virtualization—what is it, and where is it in the grand scheme of API development? To answer those two questions, what follows is a quick review on the four stages of API development, what place API virtualization occupies in the sequence, and what your company should expect to do in the steps leading to full API virtualization.

The Four Stages of API Testing: API Virtualization as the Ultimate End Goal

First off, what any newbie to APIs should know is that API virtualization is different compared to mocking, stubbing, and simulation. In other words, none of these terms are interchangeable with each other. All of them stand for a different phase of the API development process.

The timeline of an API project usually follows this sequence:

1. Developers start API development by making stubs. At the stubbing stage, API developers create virtual parts that serve as placeholders in the overall structure of the API. Just like what their name implies, these stubs have no real functionality.
2. Developers enter the mocking stage, where they test and re-test individual mocks. The next stage is the mocking stage, in which API developers create mocks or software components with only basic functionality. These mocks can only elicit a single behavioral response, and they are only intended to be used for specific testing or development tasks only.
3. Developers combine all working virtual parts in the simulation stage. At the simulation stage, API developers pool all the working parts (those assumed to have complete functionality) for limited testing and development purposes.
4. Developers produce a full virtual copy of the API in the API virtualization stage. If everything goes well, API developers can now produce a virtual copy of the API. This copy should mimic both the specifications of production and the range of behaviors possible on the fully operational API.

The first two stages, which involve stubbing and mocking the application code, can be repeated as needed before they are put in a simulation together. This is like how a chef would return to their pot in order to season and adjust the taste of their dish.

But to see the metaphor to its completion, API virtualization is just like serving a fully-cooked dish for the first time to its taste-testers, in its most complete form before it appears on the menu. Thus, API virtualization is the very last stage that API developers aspire towards before launching the API product.
Once API virtualization is achieved, it will just be a matter of tweaking and sharpening the product before it goes to the market.

Creating the Perfect Virtual Working Environment Using API Testing

Even seasoned API developers like those from Stoplight understand the need for a good working environment to test the API’s components accurately. They also need a dynamic enough platform to show what is possible for the API in different contexts. Then, and only then, will they be able to advance to the most complex stages of API development.