After API proxies are designed and built, they need to be tested and deployed into production. But these API proxies are not isolated. They’re closely networked with the target APIs/backend applications they front. Therefore, one needs to coordinate the API lifecycle and the software development lifecycle (SDLC) of these applications.
“Before software can be reusable it first has to be usable.” — Ralph Johnson
One of the fundamental phases of the API lifecycle is testing. Companies have implemented test-driven development (TDD) and behavior-driven development (BDD) approaches into application testing; as well as they use TDD and BDD to test their APIs. Companies can also leverage their application testing framework and tools to automate API testing and reduce the maintenance costs of their API catalog.
According to The State of API 2019 report by SmartBear, concentrating on testing as on a crucial step in the API lifecycle has fueled comprehensive tool adoption, with 52% of users leveraging functional testing tools like SoapUI Pro in their API development, and 46% leveraging load testing tools to ensure API performance. To highlight the importance of API testing, let’s pay attention to the fact that organizations without necessary testing face increasing support inquiries or lose users because of quality issues.
Align the API lifecycle with the SDLC
Every company has its own SDLC with various stages (such as development-testing-production). The API lifecycle should be aligned with the SDLC process.
Companies use TDD or BDD approaches to select the right tests for validating built API. In the dev environment, API proxies are created from open API specifications; otherwise, template patterns are used to generate proxies with Yeoman generators or common proxy templates. The API proxies are then attached the out-of-the-box policies like XML/JSON threat protection or OAuth2. Most organizations store the API proxies in the same repository as their application code (traditionally, GitHub).
Deploy APIs depending on workload
The destination backends of API proxies can be microservices, legacy SOAP services, cloud workloads, or services in a PaaS. Several attributes of the target application/service determine where and how API proxies should be deployed. They include:
Type of service microservices, serverless/monolith app
Existing interface RESTful API or legacy API, for example, SOAP API
Application environment: on-premises, in a public cloud, or in a PaaS
Select the case “internal consumption” or “external consumption” (partners, for example)
A company can either deploy production proxies into a centralized runtime environment or deploy proxies in a distributed mode.
In this method, the API is deployed to a core set of gateways that are either hosted in the public cloud or in an organization’s private data centers, relying on where the API management solution is deployed. Typically, for external use cases or monolith apps running in the public cloud, this is the favorite approach to minimize operational overhead. For applications with legacy interfaces that require complex transformations and processing, centralized API deployment may be the only option.
For internal use cases, microservices, or serverless apps, it’s best to make the API closer to the app environment in order to minimize latency. In these cases, the API is deployed to a lightweight API gateway that is collocated with the app or microservices, while the rest of API management services like analytics and developer services are located centrally.
Automate your testing and deployment lifecycle
In many companies, for compliance reasons and to minimize manual errors, the deployment lifecycle is automated. Most companies use continuous integration (CI) methodology and tools to automate the software development lifecycle. The API testing and deployment lifecycle can be automated using the same tools. Using the management APIs of your API platform, organizations can programmatically migrate API proxies from one environment to another.
Automating API testing and deployment speeds up detecting and fixing proxy code and integration errors, providing more frequent and successful API proxy releases.
A standard approach involves writing scripts that programmatically deploy proxies into an environment, as the stage of a massive SDLC automated process that also deploys or migrates the application code. Companies might use tools like Apache Grunt or Maven to automate their SDLC. By using such tools as Postman, it’s easier to organize the API testing and deployment lifecycle and fit into an organization’s SDLC environment.