Here’s the situation: you own an API management product, and you know you need to transform some of your payloads in order to meet consumer demands for different versions of your API. Every API management product has multiple paths to get to the same result. How do you know which one to use? How do these affect your development lifecycle? Those questions were asked of Vanick Digital by one of the country’s largest nonprofit benefits providers.
Companies like the ones we are helping are highly connected enterprises. As service providers for their members, these types of companies connect with vendors, partners, and applications in real-time in order to deliver the experience their members demand. To that end, they offer a rich set of web services that range from SOAP-style interfaces to modern RESTful APIs. What they need is the ability to abstract their backend service changes from their public API – the perfect use case for an API management gateway. In order to perfect this abstraction, though, the payloads to the external API must be transformed to meet the expectations of the backend services and vice-versa. The CA API Gateway offers a rich set of transformation capabilities to achieve this objective, but it’s not clear which capability is the right one to use when considered holistically, taking performance, developer experience, SDLC impacts, and more into consideration.
Vanick performed a benchmarking experiment to answer part of the question: which transformation method is the fastest? We constructed a CA API Gateway in the Amazon AWS cloud, matching the performance of the virtual machine to our client’s production hardware. We then wrote API gateway policies to implement four different use cases (REST to SOAP, versioning a request, versioning a response, and versioning a very large response) using three different transformation methods (XSL, XPath, and regular expressions). Whe then used Load Impact to test the Gateway’s performance under different loads. A statistical analysis of these results gave our client clear guidance on the raw performance of different ways to use the CA API Gateway to meet their needs.
A simple performance measure does not tell the whole story, however. Using our experience in best practices, we delivered a two-day on-site engagement with their Gateway team, where we weighed the performance advantages of different approaches with their impacts on developer productivity. We even considered the impacts these techniques have on handling API gateway policy as code, a key element of an effective API SDLC. Only when policies are considered a component of an overall API product – along with platform services and underlying microservices – can a transformative SDLC enter the picture, where product-aligned teams build and are responsible for entire APIs.
Our on-site engagement gave the Gateway team the confidence and knowledge to write API gateway policies with the best blend of raw performance and developer productivity. Their new standards for policy writing are now aligned with best practices and a long-term goal of digital transformation; by having a clear set of standards documents, our client can begin shifting policy from a dedicated Gateway team to individual API product-aligned teams. This improves agility by removing a gating process and builds value by allowing the Gateway team to focus on higher value functions such as governance and infrastructure performance management.