How to Virtualize APIs?


Below we use API Virtualization and API Simulation interchangeably, as synonyms.

API Virtualization creates stand-in simulations of the real APIs. See “What is API Virtualization?” for a bit more information.

Below is a brief explanation of few technologies, techniques, and approaches that implement some or all aspects of API Virtualization/Simulation.

Traditional Mocks and Stubs

What API Simulation is about may sound to some people a lot like what traditional mocks and stubs do.

Traditional mocks (fake components that in tests mimic the behavior of the real components) and stubs (which provide canned answers to calls made during a test), and other test doubles (see Gerard Meszaros’ book “xUnit Test Patterns: Refactoring Test Code”),  have been in use for long time to facilitate unit testing.

Perhaps with the exception of remote stubs, such test doubles are local – they live in the same memory space as the code that is being tested.

Developers write code to create traditional mocks and stubs. To make stubs dynamic, often times stub developers would write “if…else if…else” constructs in the stub’s code to test for certain parameters in the input to decide what output to return.

By all means – keep on coding up mocks and local stubs if that is something you already do; our recommendation is to start doing it if currently that is not something you do.

HTTP API Mocks

Somewhat new kinds of tools have been cropping up lately. These tools make it possible to stand up new HTTP web service endpoints and define static HTTP responses for them using browser-based UI. The tools’ creators call them “API Mocks” even though, arguably, they act more like remote stubs.

Most of the HTTP API mocking tools run on the Internet as Software-as-a-Service (SaaS). As such, they are suitable for applications that, when being tested, run on the Internet or can access the Internet. Reportedly, one of the leading such commercial tools and some open source implementations offer on premise installation as well.

The primary use of HTTP API mocking appears to be for validating the interface design before fully implementing it.

Service Virtualization

Instead of trying to explain Service Virtualization here, this Wikipedia article can be helpful.

There are several, commercial and open source, Service Virtualization tools out there. In our opinion, the capable and feature-rich products happen to be commercial offerings. In general, the commercial Service Virtualization products support variety of protocols in addition to HTTP, use scripting to extend functionality, have an UI to model virtual services, may integrate with other test products, and more.

Allegedly, some of the leading commercial Service Virtualization products are quite heavyweight – they require environment(s) with full-fledged application server(s) and a relational database, and may require thick client installed on someone’s workstation for the recording and modeling of virtual services; reportedly, the licensing cost can be based on the number and size of such environments.

It is certainly worth looking into Service Virtualization products for simulating services.

API Simulator

A new breed of specialized tool, API Simulator allows for the creation of sophisticated API simulations.

An API simulation consists of simlets. For synchronous request/response type of APIs, like those exposed over the HTTP protocol, each simlet simulates the output (the HTTP response) for a given input (the HTTP request).

Consider some of the properties and capabilities of simlets:

  • They complement traditional mocks and local stubs as part of development and testing.
  • Replace remote stubs for automating regression testing of existing APIs and for testing of APIs yet to be developed.
  • Substitute real APIs in integration and performance tests.
  • API Mocking is easy with API simlets – when made accessible over the Internet, they can implement everything HTTP API Mocks do, and more.
  • API simulations with simlets are configuration-driven, template-based, no coding required; scripting extends the out-of-the-box functionality, if needed.
  • Support dynamic output – output that changes based on input parameters and even from one call to the next.
  • Lightweight – create them once and share them among developers and testers by copying them onto their laptops, in applications’ test or dedicated environments as needed.
  • …and more.

For more info, you can visit the API Simulator’s web site.

<< Why Use API Virtualization? API Simulator