En APIQuality, seguimos mejorando nuestra plataforma para la creación y gestión de APIs. Con este objetivo, trabajamos para ofrecer una herramienta cada vez más completa, sacando mejoras con asiduidad. En este mes de agosto, hemos lanzado una serie de actualizaciones clave que optimizan la experiencia de usuario. Estas nuevas funcionalidades y mejoras están diseñadas para agilizar el proceso de desarrollo, mejorar la visibilidad de las ejecuciones, y aumentar la personalización dentro de la plataforma. A continuación, te presentamos las últimas novedades:
¿Qué trae de nuevo APIQuality? (octubre 2024)
Nuevo linter en el proceso de APIOps
Se ha añadido un linter (en este caso, Redocly) que permite lintear la API antes de pasar la guía de estilos de la organización.
El linter se activa dentro del ciclo de APIOps del entorno:
Este linter se puede ejecutar dentro del ciclo de vida APIOps:
También es posible revisar el resultado dentro del rating global de la API:
Añadir dominios dentro de las oportunidades
Las oportunidades pasan a poder tener dominios y la gestión de permisos se unifica con los mismos.
A partir de ahora las oportunidades se deben especificar dentro de los dominios y los permisos son los mismos que se aplican a las APIs.
Al crear la oportunidad debemos definir en qué dominio le aplica:
Generación de documentación de la API en APIQuality
Hasta el momento, la documentación que se mostraba era la generada en Microcks. Ahora, la documentación se genera directamente en la propia herramienta.
Tal y como se puede ver, dentro de la pantalla de la API existe una opción de ver documentación:
Esta pantalla permite visualizar la documentación dentro de la propia herramienta.
Generación de los openapi integrados con referencias externas
A la hora de generar nuevos ficheros con todos los enlaces href externos, se puede configurar en 3 sitios:
- A nivel de organización
- Cuando se importa un openapi
- En un Stage
Una vez activados, cuando trabajamos con el fichero con referencias se creará un fichero entregado tanto en json como en yaml, para su uso posterior para otras herramientas.
¿Quieres probar todas las novedades hoy mismo?
Explora las novedades de APIQuality y empieza a automatizar tu estrategia APIOps
Asistente para la generación de guía de estilos
Actualmente existe una serie de parámetros que son necesarios para configurar la guía de estilos y que posea una coherencia. Se ha creado un formulario para registrarlos y así crear la guía de estilos acorde con la organización:
YAML Style:
Una de las primeras cosas que se debe definir en una guía de estilos corporativa es el formato de definición de parámetros, cuerpo de entrada y cuerpo de salida.
Las reglas que se van a configurar son las siguientes:
- 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:
En esta sección se indican qué cabeceras son permitidas en la definición y cuales son las obligatorias. Se pueden excluir algunos paths de esta validación. La regla que se va a configurar es la siguiente:
- OAR033 – HttpHeaders – There are mandatory request headers and others that are not allowed
Format responses:
El importante tener una definición de objeto única para todas las apis y es un parámetro a introducir en la validación en la guía de estilos. El formato se añade en formato json. La regla que se va a configurar es la siguiente:
- OAR029 – StandardResponse – Response schema must be compliant with the standard
Paging
La paginación es importante en cada organización y se debe definir los parámetros a introducir dentro de la organización.
Status
Normalmente el /status es un endpoint de health que se pone en las apis y es bueno indicarlo dentro de la definición
- OAR030 – StatusEndpoint – Status endpoint must be declared
href
En las guías de estilo más avanzadas no sólo se valida el formato sino como se crean los openapi. Esta opción permite validar que los ejemplos, componentes, esquemas se definen en la sección de componentes.
- 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)
Parametros especiales
Es buena pragsis añadir parámetros especialices para flexibilizar la api como $select, $expand.. pero no todas las compañías lo tienen. Con este check permite habilitarlos todos de forma conjunta. Se habilitan las siguientes reglas:
- 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
Securización de las llamadas del mock
Se ha añadido una nueva opción en el settings de organización que permite securizar las llamadas del mock a través de un apikey.
Se añade una opción que permite securizar la llamada a los endpoints del mock de microcks.
Stages bloqueantes para despliegue
Se han empezado a permitir stages bloqueantes. Por el momento, sólo está disponible para la guía de estilos sonar. Para poder definir una letra mínima, se debe configurar dentro del ciclo de APIOPs dentro del entorno y seleccionar la letra mínima:
Añadir el server de mocking automáticamente
Se añade un checkbox a nivel de organización para poder activar o desactivar que se añada el server de mocking automáticamente:
Si configuramos esta opción se generarán todos los openapi con un nuevo server con la url de microcks:
Desplegar en Wso2 con api.yaml
Se ha habilitado la opción de poder desplegar en Wso2 configurando el api.yaml para la versión Wso2.
Una vez habilitado el stage, dentro del propio stage podemos configurar este fichero.
A continuación se muestra el fichero api.yaml para el entorno.
Si desplegamos la API, se puede ver en Wso2.
Consulta las Release Notes de APIQuality
Para consultar todas las actualizaciones que trae APIQuality este mes, puedes visitar nuestras release notes y verlas todas de un solo vistazo.
Además, en APIQuality encontrarás otra documentación muy interesante para aprender a trabajar con nuestra herramienta integradora de API Tools.