At APIQuality, we continue to improve our platform for the creation and management of APIs. With this goal in mind, we work to offer an increasingly complete tool, releasing improvements on a regular basis. This October, we have launched a series of key updates that optimize the user experience. These new features and enhancements are designed to streamline the development process, improve visibility of executions, and increase customization within the platform. Here’s a look at what’s new:
What's new on APIQuality? (October 2024)
New linter in the APIOps process
A linter has been added (in this case, Redocly) that allows you to linter the API before passing the organization’s style guide.
The linter is activated within the environment’s APIOps cycle:
This linter can be executed within the APIOps life cycle:
It is also possible to review the result within the overall API rating:
Add domains within opportunities
Opportunities are now able to have domains and permissions management is unified with domains.
From now on the opportunities must be specified within the domains and the permissions are the same as those applied to the APIs.
When creating the opportunity we must define in which domain it applies:
API documentation generation in APIQuality
Until now, the documentation displayed was generated in Microcks. Now, the documentation is generated directly in the tool itself.
As you can see, within the API screen there is an option to view documentation:
This screen allows you to view the documentation within the tool itself.
Generation of integrated openapi with external references
When generating new files with all the external href links, it can be configured in 3 places:
- At the organization level.
- When importing an openapi
- In a Stage
Once activated, when we work with the file with references, a file delivered in both json and yaml will be created, for later use for other tools.
Do you want to prove all these now?
Explore what’s new in APIQuality and start automating your APIOps strategy
Style guide generation wizard
Currently there are a number of parameters that are necessary to set up the style guide and make it consistent. A form has been created to register them in order to create the style guide according to the organization:
YAML Style:
One of the first things to define in a corporate style guide is the parameter definition format, input body and output body.
The rules to be configured are the following:
- OAR011 – UrlNamingConvention – The base path and resource names with more than two words must be compliant with the standard naming convention
- OAR066 – SnakeCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the snake_case naming convention
- OAR067 – CamelCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the camelCase naming convention
- OAR068 – PascalCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the PascalCase naming convention
Headers request:
This section indicates which headers are allowed in the definition and which are mandatory. Some paths can be excluded from this validation. The rule to be configured is as follows:
- OAR033 – HttpHeaders – There are mandatory request headers and others that are not allowed
Format responses:
It is important to have a unique object definition for all apis and it is a parameter to be entered in the validation in the style guide. The format is added in json format. The rule to be configured is as follows:
- OAR029 – StandardResponse – Response schema must be compliant with the standard
Paging
Paging is important in every organization and the parameters to be introduced within the organization must be defined.
Status
Normally the /status is a health endpoint that is put in the apis and it is good to indicate it in the definition.
- OAR030 – StatusEndpoint – Status endpoint must be declared
href
In the more advanced style guides not only the formatting is validated but also how the openapi are created. This option allows you to validate that the examples, components, schemas are defined in the components section.
- OAR088 – RefParam – The $ref of a parameter must end with a corresponding suffix
- OAR089 – RefRequestBody – The $ref of a request body must end with a corresponding suffix
- OAR090 – RefResponse – The $ref of a response must end with a corresponding suffix
- OAR091 – ParamOnlyRef – Parameters must contain only references ($ref)
- OAR092 – RequestBodyOnlyRef – RequestBody must contain only references ($ref)
- OAR093 – ResponseOnlyRef – Responses must contain only references ($ref)
Special parameters
It is good praxis to add special parameters to make the api more flexible like $select, $expand… but not all companies have it. With this check you can enable all of them together. The following rules are enabled:
- OAR019 – SelectParameter – the chosen parameter must be defined in this operation
- OAR020 – ExpandParameter – the chosen parameter must be defined in this operation
- OAR021 – ExcludeParameter – the chosen parameter must be defined in this operation
- OAR022 – OrderbyParameter – the chosen parameter must be defined in this operation
- OAR023 – TotalParameter – the chosen parameter must be defined in this operation
- OAR024 – StartParameter – the chosen parameter must be defined in this operation
- OAR025 – LimitParameter – the chosen parameter must be defined in this operation
- OAR028 – FilterParameter – the chosen parameter must be defined in this operation
Securization of mock calls
A new option has been added in the organization settings to secure mock calls through an apikey.
An option has been added to secure the call to the microcks mock endpoints.
Stages blockers for deployment
Blocking stages have been enabled. For the moment, it is only available for the sonar style guide. In order to define a minimum letter, it must be set within the APIOPs cycle within the environment and the minimum letter must be selected:
Add mocking server automatically
A checkbox is added at the organization level to enable or disable the mocking server to be added automatically:
If we configure this option all the openapi will be generated with a new server with the microcks url:
Deploy to Wso2 with api.yaml
The option to deploy in Wso2 has been enabled by configuring the api.yaml for the Wso2 version.
Once the stage is enabled, inside the stage itself we can configure this file.
The api.yaml file for the environment is shown below.
If we deploy the API, it can be seen in Wso2.
See APIQuality's Release Notes
To check all the updates that APIQuality brings, you can visit our release notes and see them all at a glance.
Also, in APIQuality you will find other very interesting documentation to learn how to work with our API Tools integrator tool.