In a design-first API lifecycle, it's important to help your consumers build to your API as quickly as possible. This speeds up their delivery and improves the value of your API. In this article, Vanick Digital explains the value of prototyping through service virtualization to get your API consumers building as quickly as possible.
After you’ve worked with your consumer to iterate on your initial design documents – the design sketch, the requirements breakdown structure, and the technical interface definition – you can accelerate your consumer’s integration and delivery process by providing them with a prototype. The prototype service responds to calls to the API in a fashion similar to that of the production service and allows your consumer to build their code in parallel to your service build. You also get the advantage of being able to test out any API management gateway policies that would apply to your actual service by having your gateway expose the prototype as if it were that service.
Prototyping also aids in the API lifecycle by enabling iterative design. Everyone knows that the first design of an API, even if you’ve collected good design documents and collaborated on the OpenAPI definition, isn’t going to meet all the needs the moment your consumers get their hands on it. They may find that some data types simply do not work with their software. They might discuss internally and decide they need some additional data from your API – or that they can’t handle some of the data you’re providing. They might even decide there’s a great use case that builds a lot of value if only you’d support a few new query parameters and a totally new operation. These requests almost always appear once your consumers start actually building to your service and playing with it, because at that point, the service is “real.” Prototypes allow you to catch these requests early on and iterate on your design before you get too deep into constructing your actual API and its underlying service, thereby saving you precious rework time. Updating an OpenAPI definition and a prototype should take minutes; updating, testing, and deploying a new version of a service (not to mention versioning the API that uses it) can take weeks.
You can certainly build prototypes on your own. Any developer can construct a simple service mock in an hour or two. Of course, this doesn’t include the time needed to provision infrastructure to run that service, moving it through the DevOps or traditional deployment pipeline, exposing it through a firewall, or any of the other complexities involved in exposing a net new service to the outside world. Instead, we recommend the use of a service virtualization system that can accept an OpenAPI definition and construct a virtual service that can run on a virtualized service server. This accelerates prototype delivery by removing all the deployment dependencies; virtual services are simply configurations that are uploaded to the virtualized service server, which exists in the environment as an infrastructure server, similar to your API management gateway or application performance-monitoring server. The best service virtualization solutions give you a scripting engine and connectivity to dummy data sources to make your prototypes that much more realistic.
If you choose to purchase a service virtualization system for prototyping, in our experience, CA Service Virtualization provides an excellent platform that can run many prototypes in a small footprint, has a wide range of dummy data generation options, and can create basic virtual services (“virts”) from an OpenAPI definition in seconds. We at Vanick Digital even have specialized tools we’ve created around it that can add OpenAPI request validation rules and realistic dummy data to your CA Service Virtualization virts; this lets you give your consumers an even more realistic prototype with very little additional work. These tools are available as part of our API Kickstarter engagement. However, if CA Service Virtualization is out of your price range, Smartbear offers its Service-V product through the Ready! API suite, and StopLight provides a limited, though functional, open source alternative. Each of these tools has different advantages and meets different needs. Vanick Digital has experience advising companies on which tool fits their situation best, and we’d be happy to listen to your needs and provide a recommendation.