Historial de página

...

Para realizar esta documentación se utilizará la librería SpringDoc que implementa el estándar OpenApi/Swagger.

...

1. CONFIGURACIÓN

Cambios a realizar:

 1.1 pom.xml

Añadir la versión y las dependencias:

...

1.2. application.properties

Estas variables se incluyen para la configuración local, por si se quisiera realizar alguna comprobación levantando swagger-ui, pero ya estará configurada en los entornos. NO HACE FALTA PARA LOS ENTORNOS. 
Preguntar a MNCS ante cualquier duda.

...

Deben estar declaradas previamente siguiendo la página de confluence: Migración del backend a soporte oAuth.

...

...

2. Documentar servicios

Para documentar correctamente nuestros servicios, OpenAPI/Swagger ofrecen varias anotaciones, tanto a nivel de clase como de método:

...

2.1 Anotaciones de clase

@OpenAPIDefinition (
    info = @Info(title = "TITULO DE LA APLICACIÓN", version = "${server.image:1.0}", description = "DESCRIPCIÓN DEL API."), servers = {
	@Server( url = "${springdoc.server.url}" )
} )
@SecurityScheme(	name = "OIDC",
					type = SecuritySchemeType.OPENIDCONNECT,
					openIdConnectUrl = "${springdoc.security.issuer-uri}/.well-known/openid-configuration" )

...

• title => Título que se mostrará en la documentación. Si tenemos varias clases según los recursos (como debería ser), mencionar en este title el recurso con el que se trabaja en la clase.
               P.Ej.: "Consulta de Expediente Académico", "Consulta de Datos de Afiliación", "Solicitudes de Matrícula".

• description => Descripción larga genérica de los endpoints expuestos en la clase.

• version => Versión de la documentación. Dejar exactamente el valor del código (version = "${server.image:1.0}"). 
  
  

  Info
  Solo debe haber un OpenApiDefinition por aplicación. Si nuestra aplicación cuenta con varios RestControllers (por que expone varios recursos), hay que poner la anotación @OpenApiDefinition en la clase Application principal de nuestro proyecto (la que está anotada con @SpringBootApplication).

...

2.2 Anotaciones de método

 @Operation(summary = "TITULO DEL ENDPOINT", 
            description = "DESCRIPCION DEL ENDPOINT.",
            tags = {""}, //TAG PARA AGRUPAR EN LA DOCUMENTACIÓN
            security = {@SecurityRequirement( name = "OIDC", scopes = "openid" )}, //SOLO SI EL SERVICIO ES PRIVADO 
            responses = { 
                 @ApiResponse(responseCode = "500", description="", content = @Content), 
                 @ApiResponse(responseCode = "200", 
                            description="DESCRIPCION DE LA RESPUESTA SEGÚN EL CÓDIGO DEVUELTO",
                            content= @Content(schema=@Schema(implementation=ClaseDTODevuelto.class))) 
                .... 
            })

...

Se recomienda que los servicios controlen y devuelvan un conjunto de respuestas completos, según las posibles casuísticas de éxito y error. Ver => Manejo de Errores en FundeWebJS.

• 2.3 Documentar el modelo

Para realizar una documentación completa es aconsejable documentar también el modelo de datos usado, es decir, los DTO que se emplean en los servicios.
Para documentar los DTO se utiliza la anotación @Schema ( io.swagger.v3.oas.annotations.media.Schema).

Esta notación admite muchos atributos (https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#schemaObject), pero se recomienda usar al menos "description" y "example".

Ejemplo: PuebloDTO.java:

@Schema( description = "DTO correspondiente a la tabla Pueblos" )
public class PuebloDTO {

	@Schema( description = "Campo PUE_CODIGO", example = "31104" )
	@NotBlank  //NOTACIÓN BEAN VALIDATION
	@Size( min = 5, max = 5 ) //NOTACIÓN BEAN VALIDATION
	private Integer id;

	@Schema( description = "Campo PUE_NOMBRE", example = "MURCIA", required = true ) //Se puede poner required a nivel de documentación, pero es más funcional usar @NotBlank
	private String nombre;

	@Schema( description = "Municipio donde se localiza el pueblo", example = "30 - MURCIA" )
	private PueMunicipioDTO municipio;

	@Schema( description = "Provincia donde se localiza el municipio", example = "30 - MURCIA" )
	private PueProvinciaDTO provincia;

	@Schema( description = "C.A. donde se localiza la provincia/municipio", example = "14 - REGION DE MURCIA" )
	private PueComunidadAutonomaDTO comunidadAutonoma;
......

Resultado :

Image Added

...

F.A.Q.s

• Mi servicio devuelve un ResponseEntity<miDTO>, ¿qué pongo en content?.
  

Aunque se devuelva un ResponseEntity<T>, hay que establecer el content con nuestro DTO, nunca con ResponseEntity.class.

• Y si mi servicio devuelven una lista de DTOS con ResponseEntity<List<miDTO>>, ¿cómo lo documento?.

Si nuestro servicio devuelve una lista, hay que establecer la notación content de la siguiente forma:

...

Cuando se documentan los códigos de error devueltos por nuestro servicio, si no estamos devolviendo un objeto creado por nosotros, no es necesario establecer el content para los códigos de error.
Dejar el content vacío, y que no se documente el tipo devuelto, se puede realizar de dos formas:

...

• A parte de ocultar parámetros, ¿se pueden ocultar servicios

  por

  que no

  interesa

  interese documentar?

Sí, además de la FAQ anterior para ocultar parámetros, se pueden ocultar servicios (y clases RestController completas) poniendo la anotación @Hidden (io.swagger.v3.oas.annotations.Hidden).

...

@Hidden
@GetMapping( PUBLIC_PREFIX + API_VERSION + "/healthz" )
public ResponseEntity<String> getLifeness() {
	return ResponseEntity.ok( "UP");
}

...

Referencias

• Documentación SpringDoc OpenApi: https://springdoc.org/#Introduction
• Notaciones Swagger: https://github.com/swagger-api/swagger-core/wiki/Annotations-1.5.X
• Baeldung SpringDoc OpenApi: https://www.baeldung.com/spring-rest-openapi-documentation
• Set List of Objects in Swagger API Response: https://www.baeldung.com/java-swagger-set-list-response

...