Is “API Development without Testing” a Nightmare?: Feel the Change with WSO2 API Manager 4.1.0
Someone once said,
Every night, the same dream. And every morning, the same nightmare.
Is it due to the lack of proper API Testing? Don’t worry, this article will walk through the comfortability of API Testing with WSO2 API Manager (WSO2 API-M) 4.1.0 for your integration needs.
WSO2 API-M 4.1.0 was released on the 11th of April 2022 with a bunch of new features and improvements thus enhancing building, integrating, and exposing your digital services as managed APIs in the cloud, on-premises, and hybrid architectures to drive your digital transformation strategy.
Among the API Management tasks, API Testing plays a major role. Especially, API developers think day and night about this, otherwise, API development without proper testing becomes a nightmare. Moreover, prior to releasing the APIs to the real world, the developers can perform risk assessments and take precautions by measuring practical applicability in a more real-world-like setting. It helps not only API developers but the API consumers too, to take decisions ensuring that the developed APIs are performing as expected with stability and durability.
This article discusses “How WSO2 API-M supports API testing in a nutshell?” by discussing the practical usages, features and standard measures taken.
Service Mocking and Virtualization
API Mock Implementation with API Gateway and API Microgateway (Choreo Connect)
In Rapid API Development, mostly the frontend and backend developers work parallelly to accelerate the development. Until the actual backend is ready, a mock implementation can be provided to the frontend team in order to carry out their work. So once both parties are done, a simple integration between the front and backends can be done without surprises.
In WSO2 API-M 4.1.0, a mock API backend can be simply created by selecting “Mock Implementation” without providing the actual endpoint. This allows API Providers to generate a mock payload based on an OpenAPI contract that will mock the API responses (API responses in the mock service are generated based on the examples and schemas provided in the OpenAPI specification). Furthermore, they can prototype an API using the inbuilt JavaScript engine without having to write the JavaScript implementation for each resource manually. For more information, see Mock Implementation with API Gateway and Choreo Connect).
- Prototyped APIs (Pre-Released APIs) — The APIs with the above-stated mock implementations can be deployed as Pre-Released APIs in WSO2 API-M, so that the Subscribers (App developers) can try out APIs without monetizations, allowing them to provide feedback to improve APIs. With time, after doing improvements based on the feedback from the Subscribers as well as peer API Providers, the API Publishers can Publish the API to add monetizations as required. For more information, see Expose an Existing Backend Implementation as a Prototype API. This is supported by both the Gateways, namely API Gateway and Choreo Connect. Furthermore, authentication for Prototype APIs has been introduced from APIM 4.1.0 onwards and is available by default so that the client applications can also be created using authentication to test out the APIs. If needed, authentication can be disabled for Prototype APIs at the resource level or API level.
- Deploying a REST APIs with a Mock Implementation Using the CLI of API Manager: API Controller (apictl) — Using the apictl, the API Projects can be initiated and deployed in API Manager for mock implementations containing example responses that will be referred by Choreo Connect to respond to API calls. For more information, see Deploying a REST API with a Mock Implementation via apictl. This functionality of apictl helps the CI/CD process as well.
API Virtualization with Sandbox Testing
In most industries, development practices include developing Sandbox APIs parallel to actual Production APIs in order to mitigate the risks associated with the actual transactions. Especially, the APIs that manipulate sensitive data such as payment APIs (for instance, Stripe) mandate this requirement.
The Sandbox Testing is across the board. Hence, an API Consumer can consider the real APIs and subscribe to those using applications using the Developer portal of WSO2 API-M. A separate branch can be used that consists of the sandbox access tokens that have been generated and those can be utilized for testing. Here, the most significant capability is that WSO2 API-M is intelligent enough to identify whether the API invocation should go to the Sandbox endpoint or to the Production endpoint just by recognizing the token. Therefore, at any given time, the API Consumers can seamlessly switch to the Production branch, by obtaining Production tokens by replacing those with the Sandbox ones that were previously used. From that point onwards, WSO2 API-M decides to route the invocations to the Production endpoint automatically, which reduces the API Consumer’s burden.
The API Virtualization is used underneath the implementation of Sandbox testing, where a copy of the functional API is kept that has the same standards and is identical to the Production API, but links to the sandbox backend instead of the production backend. This approach is suitable when working with APIs in the financial domain and with sensitive information.
In-built API Tryout capabilities
As API Developers — API Providers can try out the APIs and API Products using the in-built Try-Out console in the Publisher Portal in WSO2 API-M. It becomes more useful by allowing APIs and API Products to be tested in any lifecycle state except for the “retired” state (because if an API is retired, it means that its lifetime is over). For more information, see Test a REST API.
As API Consumers — After an API is published, Subscribers (App developers) can try out the APIs using the Integrated API Console in the Developer Portal by generating test keys using a subscribed application. Based on the API type, the integrated console differs in the Developer Portal.
- The OpenAPI UI — For REST APIs, the OpenAPI UI (API Console) is built-in, which allows you to visualize the API contract and interact with the API’s resources without being aware of the backend logic where you can try out each resource by just a button click. Furthermore, it provides examples for each resource as well, for instance, how the payload changes based on the content type, etc. For more information, see Test a REST API Using the Integrated API Console.
- GraphiQL UI — For GraphQL APIs, the GraphiQL UI is built-in, which supports the full GraphQL Language Specification (Queries, Mutations, Subscriptions, Fragments, Unions, directives, multiple operations per query, etc.). It provides interactive schema documentation, real-time error highlighting and reporting for queries and variables, and automatic query and variables completion. It automatically adds the required fields to the queries and also queries the history using local storage. For more information, see Test a GraphQL API Using the Integrated GraphQL Console.
Continuous Testing Services and Monitoring on APIs
Assistance for Automated Continuous Testing
The CLI of API Manager: API Controller (apictl) provides the facility to move APIs across environments such as testing, QA, development, production, etc. where the automated tests can be run in each environment using SCM polling (e.g., Trigger a Jenkins Pipeline using a GitHub webhook) within a pipelining. These tests can be based on the Postman collections, which are downloadable from the API Developer Portal, or manually written test scripts.
Moreover, for each environment, different environment-specific information such as Sandbox/Production endpoints, endpoint configurations, certificates, security-related parameters, and subscription tiers can be stored using a separate deployment repository which can be used during the automated pipeline. For more information, see Configuring Environment Specific Parameters.
The above-stated parameters can be dynamically changed based on the testing requirements using the environment variables notation supported by apictl. For more information, see Using Dynamic Data in apictl Projects.
Furthermore, testing can be automated without a hassle by using auto-generated SDKs as well.
AB Testing
AB testing scenarios can be easily implemented with the help of in-built features such as dynamic API endpoints and analytics on backend usage. A developer can simply create and publish an API with a dynamic backend where the API traffic will be routed to different endpoints based on a given mediation rule (i.e., request header). After deploying the API, its traffic can be monitored for some time and a preferred API backend can be selected by referring to the Backend request count reports generated by the WSO2 API Analytics Dashboards.
API Monitoring
The APIs can be monitored using different methods after they are published as explained below.
- Cloud-based Analytics — All of WSO2 customers get the free Cloud-based Analytics Solution — Choreo Insights for their API usage with WSO2 API-M 4.1.0. It continuously monitors each API after it is published for metrics such as error responses, performance drops, missing responses, throttling related data, authentication etc. It provides a dashboard that indicates the health of an API. This solution provides graphs for each of the above-stated information by default which makes it easy to troubleshoot and find the root cause. Alerts can be generated when predefined thresholds are exceeded for certain metrics like response time and returning faulty status codes. Moreover, if there are any custom requirements, this has the ability to provide support with custom dashboards and widgets. This also provides the standard GraphQL APIs, to pull the summarized data out for billing, monitoring, and auditing purposes. Furthermore, the data protection regulations have been honoured here, while also attaining privacy-related certifications and guaranteeing data retention and uptime. For more information, see API Analytics Getting Started Guide.
- On-prem Analytics — The users who are willing to use an on-premise analytics solution can publish the analytics data into a log file and that file will be used as the source for the analytics solution. This is an ELK (Elasticsearch, Logstash, and Kibana) based solution where you can use Kibana dashboards to monitor your API Management related statistics. For example, API traffic, Errors, Latency, Cache, and Devices are a few dashboards. For more information, see ELK Based Analytics Installation Guide.
Developer Portal Assistance
The Developer Portal allows downloading the API’s definition in OpenAPI or GraphQL specifications, client SDKs for multiple languages, and the Postman collection for the API. These artifacts can be used to easily generate automation test suites or integrate with monitoring platforms like Site24x7 to derive insights on uptime, availability, and performance.
Testing of a portfolio of APIs for Consistency and Quality
Securing APIs by Auditing API Definitions
API developers in WSO2 API-M can conduct security audits on the Open API Specification (OAS) of the API and ensure the API meets security requirements. WSO2 API-M has partnered with 42Crunch, the only enterprise API security platform, to bring in the ability to conduct a security audit on the OpenAPI Specification definition and to obtain an audit report. For more information, see Securing APIs by Auditing API Definitions.
Workflows
For design-time governance of quality and consistency, API developer workflows can be engaged to check an API’s schema against defined standards and best practice guidelines.
API Linting
This allows you to maintain consistency by checking whether all the APIs are validated to a set of additional constraints. API linters such as Spectral can be used here through an extension point of WSO API-M. For instance, rule-based validations or regular expressions-based validation can be done for certain properties such as an email field, telephone number, etc.
API Templating
An API’s Gateway configuration file (Synapse configuration) content contains API metadata, API resource information, properties, etc. and it is generated based on the API template file that maintains consistency across all the APIs. This template can be modified as the user wishes by engaging a custom handler based on API Properties. For more information, see Customizing API Template.
Support of Compliance Check of an API to your specification or customized style guide
Compliance checks: Design time
API definitions that are imported to API Manager are validated against corresponding specifications based on the API type as listed below to verify its compliance. Similarly, the same compliance checks are performed for the APIs which are being created and designed from scratch.
- REST APIs — Open API Specification (OAS)
- GraphQL APIs — Schema Definition Language (SDL)
- Async APIs- Async API Specification
At API design time, the developers can conduct security audits on the OAS of the API. The security auditing will perform data validations and compliance checks for security mechanisms applied, and verify whether the protocols are secured enough and whether the best practices are followed.
Meanwhile, the API projects which are imported via the apictl will be validated against the same standards and specifications as well.
Furthermore, using an extension point, API Linting capabilities can be incorporated to not only validate the technical correctness of the API specification but also comply with a set of additional constraints that often are documented in the form of API guidelines. You can customize your own rules set apart from the standard validations that happen through the OAS, to apply for all the APIs using this capability.
Compliance checks: Runtime
The API request and response schema validation can be enabled per API. The schema validator validates the API requests and responses against the request/response schemas, parameter definitions, etc., that are defined in the API’s OAS. For more information see JSON Schema Validator.
Wrapping things up…
For a newbie to the API-M family, this article will be helpful to know everything in just a snap of your fingers related to API Testing with WSO2 API-M 4.1.0. Moreover, we discussed the practical usages and standards followed by API-M to make testing tasks easy, user-friendly and to keep up with industry standards.
Furthermore, I believe, even though you are not a newbie to WSO2 API-M, you might have found some interesting points in this article to try out by yourself.
Stay tuned guys… Goodbye until the next time…. Stay safe everyone!
