API design is a complex topic — what works for some providers does not for others. It seems that with each year, new approaches are developed, and new thoughts on how APIs fit into the overall platform strategy emerge. We’re specifically seeing this occur in banking, as market trends force more agile ways of bringing innovative software to life.

The traditional cycle is to build, gather feedback, iterate, and then gather feedback. The problem is that this cycle is inefficient, and each stage is developed almost in isolation. A more experimental design process could curb this inefficiency — and that’s what the folks at Capital One DevExchange are attempting.

Today, we’re going to discuss an API design and testing approach that Capital One has dubbed an “experimental API strategy” in a DevExchange blog post. We’ll see how they define an experimental API, and think about the various benefits and drawbacks of its implementation. We’ll also note some potential situations that could benefit from experimental APIs.

What is an Experimental API?

An experimental API is exactly what it sounds like – an API that is meant to facilitate experimental work. It’s typically a mock service that utilizes simulated data for processing and development — this is akin to the approach used by server codebase developers when using artificial data on a staging server to load test and iteratively build new services.

The idea here is to engage the community, and in many cases, the experimental API will also allow real data (though limited in nature) for experimental functionality and processing. This allows the community to interact with the codebase and to drive new additions and features through targeted, informed feedback.

This informed feedback is a main benefit behind the experimental APIs at Capital One. It’s allowing them to test and iterate the Money Movement and Virtual Card Numbers APIs.

“Experimental APIs are mock services that use simulated data to mimic API functions. They are designed with the goal of getting early feedback from the community around API desirability and design before the product release.”

By eschewing a traditional lifecycle, software developers can create a holistic development cycle that gathers feedback dynamically as each iteration in the build process occurs. As opposed to a traditional cycle, experimental APIs could bring a more effective development cycle. However, these benefits are not entirely assured or guaranteed – more on that in a moment.

Benefits of an Experimental API Approach

The obvious benefit behind an experimental API approach is the low latency between building and testing. Since information and response is gathered during the building and iteration process, feedback is much more dynamic. This has the ultimate response of making development itself based upon consumer response, rather than a generalized guideline.

“With these APIs, we’re extending a more intimate relationship to developers and potential partners.”

Additionally, gaps in coverage and function can be identified through this feedback, allowing for more complete code to be developed. The fact that everything is taken holistically also allows for a greater amount of compatibility, allowing features to coexist in equilibrium instead of having them be coded later on to fill a gap in function.

This type of design approach can also help in narrowing the scope of the project, preventing feature creep. Often, creep arises because the developer thinks that something is needed when the user has yet to identify it as such, or because the additional content itself requires further coded systems to support it. By sticking strictly to user feedback and constraining development to that which is requested, the provider could alleviate this.

Additionally, this approach is great for testing. Since the bulk of data is either not real or severely limited, many of the security threats inherent in testing with real data can be avoided.

Drawbacks of an Experimental Approach

While there are a great many potential benefits to adopting an experimental approach, there’s also a lot of possible negatives that should be considered. Depending on user feedback for iteration makes for a more customized product, but it can also create an infinite loop of constant iteration creep if there’s no end date set and resource limitation understood.

The limitation of effort to new function should not only be understood by the developer, but also communicated clearly to the user — in other words, the user utilizing the experimental API should be made fully aware that not every piece of feedback is going to be utilized, and that some features will have to remain in place considering the security and efficacy of the systems in question.

While using fake data helps a lot in terms of security, exposing the API as its security approach is created and evolved can also create a veritable roadmap for future exposure. The possible attackers of tomorrow will have watched security evolve from day one, and will be aware of intricacies and eccentricities that may not otherwise have been exposed. While this is not really a strong reason to ignore the approach altogether — in many cases, security development can be effectively obfuscated to the point where it’s a non-issue — it should be considered a vulnerability if not addressed.

Additionally, there is the obvious expansion of dependence on versioning that should be acknowledged. An experimental API is essentially a great many versioned builds stacked together into an active development lifecycle, so everything has to be versioned, tracked, updated, etc. with greater frequency than traditional development approaches. This can easily overwhelm smaller developer teams and lead to loss of version control as development grows more complex.

Set Goalposts to Avoid An Eternal Alpha

When we’re discussing an experimental API strategy, we need to consider the idea of the eternal alpha .Without proper iteration control and goalposts, this type of development is essentially an eternal alpha build of your final product. While this was somewhat discussed within the concept of creep, the problem is much more foundational — at what point is a minimum viable product created, and at what point is it time to call development quits or separate the functions into a new microservice?

This is going to be different for every developer, so it’s hard to give advice here on that particular issue. That being said, having any sort of guideline and eventual goal will help mitigate much of this potential issue. Have a set plan for what constitutes the difference between the experimental API and the release API, and who is going to use what.

It might make sense to isolate the experimental API from the userbase entirely and instead request comments for development, and in some cases, it might make sense to make the release build an experimental build itself. Regardless, at a certain point, you are going to need to establish scope and decide what exactly makes an alpha morph into a beta, and a beta into a release candidate.

A Forked Approach

One method of implementing an experimental API is to have both a release branch and the experimental branch. A release branch is a stable build, only changed from the results of the experimental. The other branch should be the experimental one, constantly evolving and changing, utilizing new methods and limited user data blended with existing methods and fake data.

This approach allows businesses and partners to utilize the stable API for basic functions, but also allows users to opt in to using the experimental branch for additional functionality, assuming of course that they understand it’s not stable, it might break, and it’s nowhere near release. This also gets around the issue of scope, as the minimum viable product is already there, and everything else is iteration to add further functionality.

Judging Appropriateness

Of course, with all of this being said, there was some specific “flags” that suggest whether or not an experimental API is an appropriate approach. For one thing, any API working with high secure information, especially PHI, will at least want to use nothing but false data for the experimental API, if not avoiding the approach altogether. Even with false data, utilizing an experimental API will expose the security underlying the system itself, and could expose how the data is stored, exposed, and worked up.

For APIs that tie into other API systems, providers may want to obfuscate some of that interaction, as citing internal endpoints that may not be documented can be concerning to the partners in question. In these cases, the exposure is more concerning for partner APIs, but nonetheless, it contributes greatly to insecurity across all the APIs in the network.

APIs intending to be lean should also avoid experimental development. The problem here is that low funded APIs or those with a focus on lean by design necessarily means the scope has to be very well-defined and limited, and experimental approaches fly in the face of that.

Community centric APIs that focus on community needs rather than specific business cases could benefit from this development approach as it results in greater development speed and efficacy. Additionally, APIs rooted in bleeding edge solutions could reap huge benefits from this approach, as it may not be clear how to apply the specific technology or solution for the given situation unless the community speaks up and delivers feedback.

Finally, perhaps the strongest argument for this type of development is the business to business API. With an experimental API, the partner businesses and their community can state what they want, what works, what doesn’t, etc., which can unify legacy and modern systems (assuming you are obfuscating in ways that you need to for security).

API Design Thinking Gets Experimental

For Capital One, their experimental APIs are part of their design thinking process, which they define as “a practice in product development that centers the needs of users in the products you’re trying to build.” This helps prototyping without contracts, early user testing, and iterative feedback.

Ultimately, the concept behind an experimental API is a promising approach that should be paired with a sensible situation. While an experimental API could have some huge benefits for many providers, not everybody is going to benefit from this type of development approach. In fact, many ultra-lean providers could suffer from this type of implementation.

That being said, if your organizational requirements and API design ethos match up with this approach, and the experimental API is appropriate in your particular case, adopting it can result in some huge gains to efficacy, development speed, and general functionality.