Today’s software architecture relies on APIs as core to the application in much the same way as a database or user interface are considered core components to the architecture. That reliance on APIs means that application testers have to test the application’s reaction to a variety of API responses. But, if those APIs are still in development or are developed by a third party, how can you fully test against them? This is where an API sandbox comes in. Fundamentally, an API sandbox is an environment that testers can use to mimic the characteristics of the production environment and create simulated responses from all APIs the application relies on.

 

The API sandbox makes it possible to:

  • reduce the cost and risk associated with calling 3rd party APIs during testing.
  • allow for concurrent testing and development to fast-track app development cycles and reduce time-to-market.
  • simulate error scenarios with your API, like latency in the API’s response time, error conditions or simulating a non-responsive API completely.

 

Defining API Virtualization

There are all kinds of services available today to make your development experience faster and less expensive. By using components created by other parties to perform common tasks, you can focus on the elements that are unique to your application. In effect, you’re using someone else’s code to speed up your own development cycle and to make maintenance less of an issue.

Unfortunately, a major problem in using third party components is that their development cycles seldom match your own. Delays result when you need to wait for a dependent API to become available. However, API virtualization overcomes this issue by emulating the dependent API until it becomes available. Instead of using the actual API, you use a virtual service as a stand-in for the API. The application under test still uses the same calls as before but points to the virtual API, which makes it possible to perform specific tests by simulating environment conditions or API responses. An API virtualization tool requires these sorts of features:

  • bandwidth throttling and server settings to test an application’s response to an overwhelmed API.
  • error conditions that make it possible to test an application’s ability to handle APIs that are down or simply unavailable for some reason.
  • ability to define virtual services that you or a third party can use to build and test against.
  • ability to develop and test in parallel.
  • provision for supporting third party developers who need to perform integration testing.

 

The main advantage of using API virtualization is that application testing can begin almost immediately. Without virtual APIs, application teams have to wait until APIs are nearly complete before testing could begin in earnest, which meant that errors were harder than necessary to fix because a lot of the code was already finalized. Using API virtualization means that the testing process can begin earlier and problems fixed with greater ease.

It’s important to note that API virtualization isn’t the same as server virtualization or the creation of a virtual machine. The latter two create an entire system, with all its complexity. When working with API virtualization, the only virtual asset is the API, which makes the virtualization itself a significantly easier process.

Creating a Powerful and Affordable API Sandbox

Whether you are an API consumer or an API provider, having an API sandbox is a powerful way to harden any applications that use APIs. Creating a really great sandbox requires a few key considerations.

Sharing Assets

Of course, you can create a sandbox for your own exclusive use. But if you are an API provider, you probably want to create a sandbox for third party developers to use. If you’re an API consumer, having a shared environment also allows you to leverage the virtual APIs created by other members of your team. An easily accessible environment is:

  • discoverable on your network
  • available 24/7
  • able to host multiple virtual APIs
  • allows unlimited users to log in and use the virtual APIs

 

Designing virtual APIs

Designing an API sandbox starts with understanding the use cases of your consumers. Virtual APIs can be powerful assets but only if they are planned and built with those use cases in mind. Let’s look at a few of the most common use cases and how you can design virtual APIs to accommodate them.

API Still in Development

If an API is still in development, it poses a problem for testers who need to access and test the functionality that depends on that API. However, that’s a solvable problem as long as the API has a service description. If there is an existing WSDL, WADL, Swagger, RAML, API Blueprint, or I/O Doc for the API, you can identify valid requests and responses based on those definitions.

API Error Codes

One of the most important steps in testing is simulating back-end failures to ensure that those failures are trapped and handled elegantly by the front-end code. In the case of APIs, some of those APIs used by the application may be live third-party APIs, making any kind of simulation impossible. An API virtualization tool lets you create a virtual API for each error code you want to test against, ensuring that your application doesn’t expose the error directly to your users. For example, you may want to create a virtual Maps API that responds with “Internal Server Error (500): OperationTimedOut” and another virtual Maps API that responds with “Forbidden (403): InsufficientAccountPermissions”.Then you can construct your tests to verify that your application handles both of those responses adequately.

Application Load Testing

Load testing is an important step in qualifying an application for production but requires a significant amount of data and server capacity. For those reasons, it’s very difficult to load test a live API – in fact, most API providers will see this activity as a Denial of Service attack and will cut off access. Creating a virtual API to use in your application load tests solves that issue but still requires a significant amount of work in creating the data for the load test itself. Some API virtualization tools provide data generation for virtual APIs, which lets you generate thousands of records that you can use as input during your load tests.

In Conclusion

The bottom line is that using an API sandbox reduces risks and costs. Development teams can deploy more confidently because everything is fully tested using virtual APIs to simulate a variety of errors. Because no one is getting in anyone else’s way, the project completes on time and within budget. You gain a competitive edge and keep it longer, which is always good for the bottom line.

Written by: John Paul Mueller

Further Resources

Subscribe to our mailing list

* indicates required
I'm interested in...

Want to save time and money testing your APIs?

Try ServiceV

How to Succeed in an Increasingly Connected World

Read Now