Simulated environments are not a foreign concept in web development. Especially for application programming interfaces — APIs — that may need to create a simulation of their service for testing purposes, virtualization is an option that can go beyond your average API explorer or GUI.

Following the Dropbox API explorer enhcnacement release, now Amazon has recently announced a mock integration feature to their API gateway. Virtualization takes mock testing a step further, allowing API calls and simulated responses to be coded into early stage app development, enabling both API providers and API developers to gauge performance in quite fine-grained ways prior to an official API launch.

And as web API development becomes more iterative and constantly in flux (According to Michael Wawra of Twilio, your API is never really finished), some providers are pushing simulation as the solution to help keep an entire API platform agile.

What is Service Virtualization?

In the programming world, Service Virtualization is a method of abstracting the behavior of cloud driven applications. “Mocking on steroids,” virtualization doesn’t just mock a specific function, it emulates the same performance as an end product would. Developer operations can use virtual services to begin functional, integration, and performance testing early on, rather than after an official product launch.

Why virtualize a product? For physical products it may mean avoiding a major recall. In his talk with Nordic APIs, Matti Hjelm references LEGO’s failed Fun Snacks. Made in the shape of lego bricks, parents became furious with LEGO for teaching kids to eat things that look like identical to the normal LEGO bricks.

In hindsight, LEGO’s Fun Snacks lacked the proper user testing. For web services, virtualization can similarly help with that quality assurance aspect and simulate actual behaviour, capture information, and use feedback to replace or change components — hopefully to avoid the choking hazard for developers and end users.

What is API Virtualization?

API virtualization allows you to isolate components and simulate external, non-network based APIs. This runtime behaviour simulation uses a tool in place of the real mcCoy — a virtual copy of your API that mirrors behaviour of the final production version.

In web software, an error-free finished product is a daydream. Instead, rapid (and continuous) development cycles occur that need immediate testing. Next we’ll outline five benefits that API virtualization can bring to the table.

1: Test Failure in a Safe Environment

Want to see how error messages function? How rate limits work? From a user’s perspective, a virtual API looks and behaves like a real service. However, distanced from live runtime, virtualization can be used for simulating drastic scenarios. Use an emulator to simulate real world behavior like downtime, slow or erratic API responses to see how an app behaves when confronted with these dilemmas.

A great test can provide the information on what happens when a client calls an API that suddenly responds strangely, and do so in a neutral, risk-free setting.

2: Increase Development Productivity

Dependency injection is a messy situation, and writing mocks are useless for developers in the long run. API virtualization allows the ability to reduce redundancies in the development cycle and emphasize a more seamless continuous integration process.

Desktop Software Maturity Stages

According to Matti Hjeml of SmartBear, typical desktop software can be said to have a development lifecycle made up of these stages:

• 1: The technology stage. You develop your core functionality with a simple, non-cluttered User Interface (UI).
• 2: To stay ahead of competitors or in response to customer inquiries, features are added. Design may become 2nd priority in this stage, leading to UI clutter.
• 3: Customers ask for simplicity in response to a cluttered UI.
• 4: Software becomes a commodity, and integrates with other software, plugins, or other tools through the use of embeddables, plugins, SDKs, etc.

API Market Stages

Hjmel sees a very similar development cycle within the API market:

• 1: Unique feature set, hard to use?
• 2: Add features to keep competitors behind
• 3: Improve DX to keep 3rd party devs coming back

A significant aspect of stage three, improving developer experience, is serving the API with the proper testing environments. Whether with interactive documentation, sandbox, or virtual API, having a way to test an API is an important cog to complement your developer ecosystem.

3. Isolated Performance Testing Saves Money

In normal app development practice, you may simulate other APIs, but in the process become too independent, using mock code that mimics the API that you don’t have control of yourself. By virtualizing your own API, API platform providers can erase these type of headaches, and allow more sharing with the API developer users. However, this must be done with tact.

Share Testing Environment

Why don’t you simply share a testing environment running on internal servers with the user? According to Hjelm,

“The problem is that in this new economy user needs are unpredictable. It’s not like the SOA world where you had control of which were the users and when they were allowed to use your system… There is no predictability when and where the API calls are coming from and how much.”

If general usage is unpredictable, most likely the testing is unpredictable as well. The bandwidth cost for large random testing can be a strain on an API provider’s server. So…

Encourage Local Testing

To combat this problem, Hjelm encourages providers to “build shareable and distributable virtualized versions of your API.” This can simplify testing locally, and empower developers with autonomy and control. It still shows an active engagement from the platform owner in third party testing, integration, and development.

Running test servers can be costly, and demands for performance testing are largely unknown in early stage development. If the micro costs incurred for API calls are adding up, an API developer could save money using a virtualized API, rather than performance testing on the production version.

4. Reduce Time to Market

APIs are distinct from normal products, as potential revenue relies on a long, two-product lifecycle. First is the API product lifecycle itself, in which one must plan, develop, and form an ecosystem of developer consumers. After this tremendous feat, APIs rely on developers to create successful apps before a significant quantity of calls are made (and income generated for the API provider).

By using virtualization techniques, however, this cycle can be significantly cut down. By offering a virtual API in a continuous development mode, third party developers can start building applications before the actual endpoint is live. This could significantly reduce the time from when the API is developed to the first call being made by an end user within a third party application.

5. Virtualization Can be Usable

A virtual API must emulate the core functionality of your normal API, and more. It should be able to simulate awkward behaviour, or slow response time — natural occurrences, and respond with typical error messages. It should be easily configurable, supporting security with OAuth 2. As Hjelm says, design your virtual API as data driven, distributable, and deployable locally.

“By recording and storing known answers to predictable requests, then simulating the service and playing back known (“canned”) data, API Virtualization allows build systems to do more, with faster, more predictable results. This does not remove the need for end-to-end testing, but it does allow the team to have more confidence with each build.”
— Matthew Heuser

One may think that this is a difficult process, but it can be implemented in a few steps. In a previous post, we used SmarBear’s ReadyAPI service to mock the endpoint of a REST API and create a virtual service in about 20 steps.

Safe Harbor: Drawbacks, Risks, and Mitigations

• Virtual Insanity: There is the risk that the production API won’t match the virtual API that has been used for testing. Teams must have automated checks in place for end-to-end testing when using the production API.
• Analytics: How do I analyze usage patterns? You can use in-app Google Analytics.
• Complex Maintenance: According to Hjelm, it shouldn’t be hard to maintain a virtual API, as APIs deliver simplistic views of complexity.

“Virtualize Me” -Your API

Virtualizing your test environment, and doing so often, and early on, can accelerate rapid development cycles, and increase internal productivity. Some argue that the future will see the emergence of more Sandbox-as-a-services and complex simulation environments. As Kin Lane says:

“I’m seeing services emerge to cater to this need, as with Sandbox, which is a service layer of the API lifecycle I think will only grow in coming months. I can see the need to create simple sandbox for any APIs as you are kicking tires, but I can also see the need for sophisticated simulation environments built on top of common APIs, allowing some apps to test out more advanced, and specialized scenarios.”

Benefits of API Virtualization

API virtualization allows quickly curated versions of the API for your developer ecosystem to emulate immediately. To review, the benefits of API virtualization can include:

• Increased overall productivity
• Shorter time to market
• A true environment for third-party sandboxing
• Test real world scenarios without the risk
• Eliminate the need for individual developers to write and rewrite their own mocks

Other Resources on API Virtualization, Sandboxes:

• Walkthrough Creating a Virtual Service Ready API, Nordic APIs
• Patterns of API Virtualization
• What is API Virtualization?
• What is an API Sandbox?
• API Virtualization, Sam Ramji
• I Wish all APIs had Sandbox Environment by Default, API Evangelist
• Virtualized API Stacks, API Evangelist
• Sandbox
• RESTful API Design: API Virtualization, Brian Mulloy | Apigee
• Service Virtualization as an Alternative to Mocking