Interface Completeness

La documentación deficiente es uno de los problemas más frecuentes que enfrentan los consumidores de APIs. Por ejemplo, los recursos a menudo no tienen una descripción que nos muestre para qué sirven y las solicitudes a menudo fallan sin que la devolución nos diga qué debemos hacer para completar la llamada. Los problemas de este tipo se pueden evitar si existe una gobernanza que establezca que las APIs solo se pueden implementar en un entorno de producción si su documentación es suficiente.

Sensedia desarrolló la función Interface Completeness precisamente para ayudarlo a visualizar qué tan completa es la documentación de una API.

No hay una pantalla específica para Interface Completeness; se muestra en la esquina superior derecha de la pantalla Overview de una API:

completeness

La función analiza el Swagger de la API y compara la cantidad de campos que tiene con la cantidad total de campos que podrían incluirse en un archivo Swagger. Según esta comparación, muestra un porcentaje para representar el grado de completud del archivo. Además, en función de los problemas detectados, ofrece sugerencias para que pueda mejorar la documentación (lee más sobre esto más abajo).

Con esto, puede:

  • utilizar el porcentaje de completud como requisito para promover las APIs de una etapa de workflow a otra (ver más sobre esto a continuación);

  • asegúrarse de que la API que está exponiendo al público en su Portal de Desarrolladores esté suficientemente documentada (puede elegir exhibir las APIs en el Portal en la pantalla Overview de la API).

¿Cómo puedo interpretar el porcentaje de Interface Completeness?

Para llegar al porcentaje final, comparamos la cantidad de campos que tiene su archivo Swagger con la cantidad total de campos que podrían incluirse. Utilizando nuestra experiencia en APIs, asignamos diferentes pesos a los campos para valorar los elementos que son más importantes (por ejemplo, incluir códigos de retorno HTTP es más importante que describir el error). También validamos el formato de algunos campos, por ejemplo:

  • las descripciones deben tener una cantidad de caracteres mínima y no pueden ser secuencias como ABC o 123;

  • La ruta base de la API debe incluir su nombre y versión, que deben coincidir con el nombre y la versión registrados.

De todos modos, el resultado final es cuantitativo, no cualitativo: proporciona una medida de completud de la documentación, no dice nada de la calidad del diseño. Por ejemplo, verificamos si su API tiene una descripción, no si la descripción se adapta bien a lo que hace la API o si es clara para el consumidor. Puede y debe usar este porcentaje como una etapa de verificación antes de exponer la API, asegurándose de que el Swagger esté suficientemente completo, pero no como una validación de la calidad de la API.

En cuanto al valor porcentual que podría funcionar como un umbral de completud, esto depende de su estrategia de APIs y de los objetivos de cada API que diseñe. Es por eso que puede definir cualquier valor que desee para Interface Completeness como un requisito para promover las APIs de una etapa de workflow a otra (vea más sobre esto a continuación).

Según nuestra experiencia con APIs y documentación de APIs, sugerimos que ninguna API se exponga al público si no alcanza un mínimo del 70% de Interface Completeness. Más que eso, sugerimos que el 85% indique una documentación muy buena, por lo que es incluso mejor utilizar este valor como umbral. Pero esto es solo una sugerencia; como todo en la gobernanza de APIs adaptativa, no dude en establecer el valor de umbral que funcione para su contexto.

Sugerencias para mejorar el archivo Swagger

La herramienta también muestra sugerencias de mejora después de verificar los campos del archivo Swagger. Para verlas, haga clic en Suggestions, debajo del porcentaje.

Puedes hacer modificaciones usando el editor Swagger (ver más información al respecto aquí).

Después de realizar los cambios y guardar su API como una nueva revisión, la evaluación de completud se realiza nuevamente.

Ejemplo de uso

Creamos una API con descripción y ruta base, pero no incluimos ningún recurso, lo que generó un bajo nivel de completud:

completeness ex1

Luego, incluimos estos dos recursos:
completeness ex2 resources

Usando el editor Swagger del Manager, incluimos los tipos de devolución de cada recurso, mensajes de error con los códigos de respuesta HTTP para cada recurso y descripciones de algunas propiedades del modelo. Nuestra API ahora está lista para ser expuesta:

completeness ex2

Campos comprobados

Estos son los campos que la funcionalidad comprueba para evaluar la completud de la documentación de la API (recordando que hay diferentes pesos para cada uno):

API Recurso/Operación Modelo
  • Título

  • Descripción

  • Versión

  • Ruta base

  • Recurso

  • Resumen de operación

  • Descripción de operación

  • Nombre de parámetro

  • Descripción de parámetro

  • Código de respuesta de operación

  • Descripción de respuesta de operación

  • Nombre de header de respuesta de operación

  • Descripción de header de respuesta de operación

  • Nombre

  • Descripción

  • Nombre de propiedad

  • Descripción de propiedad

Cómo utilizar Interface Completeness con Workflows

La función Workflows controla las etapas del desarrollo de APIs. Permite personalizar los requisitos para que una API sea promovida entre las etapas, lo que le da visibilidad y control del proceso de desarrollo de cada API.

Uno de los requisitos que se puede establecer es un porcentaje mínimo de Interface Completeness. En este caso, si define que solo las APIs con al menos un 85% de completud deben estar en la etapa «Production» y también incluye el requisito de que solo las APIs de esta etapa se pueden implementar en un entorno de producción, entonces efectivamente establece que las APIs solo se pueden implementar para el público con documentación satisfactoria.

Puede leer más sobre Workflows aquí.

Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]