API Governance using MuleSoft
Earlier this year, MuleSoft introduced a new offering within the Anypoint Platform: API Governance. As noted within the documentation: “Anypoint API Governance is a component of the Anypoint Platform that enables you to apply governance rules to your APIs as part of the API lifecycle”.
Why API Governance?
The word governance can sometimes elicit a negative connotation, it can be viewed as being too restrictive, time consuming, or additional overhead. If this has been your experience in the past with governance, think about the following painful, real-life scenarios that can occur when consuming an API:
· API is not documented correctly, incompletely or not at all leaving much to interpretation
· Inconsistency or standards not followed across an APIs resources, methods, payloads, etc.
· Security not standardized or worse yet, not as secure as what would be expected
· Error handling is not consistent with API documentation, such that consuming an error response was customized across various endpoints
· Versioning is not consistent and does not follow any standards (i.e. major, minor, patch)
· Custom code is written to handle different error scenarios (because of one off, inconsistencies) when consuming an API
· Understanding of the API use and function is difficult due to non-standardized usage and open to interpretation (which is always dangerous)
· Lack of payload examples make consuming an API a exercise in trial and error to understand the requests and responses
These are just some of the difficulties that can arise that make consuming an API difficult at best. Additional time is needed to analyze what the API really does; development time can be elongated due to the unknowns of the API; assumptions are made that may result in bugs found in QA or even production.
Given the challenges just laid out, what is the best way to enable your APIs to follow best practices and standards that provide the following qualities:
· Easily reused, updated, extended
· More reliable consumer experience
· Better quality, consistency, and compliance
This is where API Governance comes in. The new MuleSoft API Governance component is a way for your organization to define how APIs should be defined and designed according to the defined standards, best practices and principles that are specific to implementation needs. Time spent up front, defining these governance rules, along with applying them during design and initial deployment allows for development of quality APIs.
Within this blog post, the capabilities that are available in this new governance component will be highlighted, demonstrating how this new tool can be used to implement API governance.
Rulesets
Rulesets are used to define the governance rules by which an API will be deemed compliant. Compliance ensures that APIs follow the standards and best practice that have been defined within an organization.
The rulesets are assets which reside within Anypoint Exchange and MuleSoft has provided several rulesets that adhere to industry best practices. These include:
· OpenAPI best practices
· Anypoint best practices
· Authentication Security best practices
· AsyncAPI best practices
· OWASP API Security checklist
Each of these has defined violations or warnings that will, when applied to an API, ensure the given API adheres to these standards and best practices. Violations will cause the API to be flagged as being “Not Conformant”, meaning that the API asset failed to meet the criteria defined as required by the governance rules.
For example, an API has the Authentication Security Best Practices ruleset applied to it. If the API specification (i.e. RAML, OAS) has not been defined with the security field, it will be deemed as “Not Conformant”:
The conformance is validated once an API is published to Exchange from Design Center and the conformance status is visible within Exchange for a given API, as shown above.
Customized Rulesets
While MuleSoft has provided several rulesets, they may not provide the exact governance rules required. Since rulesets are defined by a series of rules within a YAML file, an existing ruleset can be cloned, customized, then published to Exchange.
A new ruleset can also be implemented, with the desired governance rules. See documentation for details on the format and contents needed for defining the rules within a ruleset YAML file. Just like the cloned ruleset, the new ruleset will be published to Exchange.
Design Center
Much like how a fragment is used, ruleset(s) can also be imported from Exchange into the API definition within the Design Center. This allows an architect to catch governance inconsistencies early during the design phase of an API.
API Governance Dashboard
As mentioned earlier, Anypoint Exchange provides an overview of the conformance status for a given API. Within the API Governance dashboard, conformance status can also be viewed for a given API, as well as overall conformance for all APIs being governed, including the severity of the conformance:
In the above screenshot, you may have noticed “Profiles”. Profiles are created to apply the rulesets needed to govern one or more APIs. When defining a profile, configurations are available to qualify which APIs will be governed by the defined profile.
This includes:
· Ruleset(s), selected from Exchange, that will be used to govern the API(s)
· Criteria used to apply the governance ruleset (i.e., REST API vs. AsyncAPI)
· Optional criteria (tag, category, lifecycle) used for designating governance in a more granular level (i.e., govern only system APIs)
· Who to notify, via Email, when an API is not conformant according to the defined ruleset
API Governance CLI
Another way to ensure that an API is adhering to the defined API governance, there are CLI commands that can be used to verify the compliance within the CI/CD pipeline ( e.g. CLI command: “governance api validate”). Further details can be found in documentation.
Using the new MuleSoft API Governance component within Anypoint Platform enables quality APIs to be implemented.
