Me di cuenta de que typescript/angular2
codegen genera un código extraño relacionado con el manejo de errores:
/**
* Add user
*
* <strong i="8">@param</strong> user username
* <strong i="9">@param</strong> passwd passwd
*/
public create(user: string, passwd: string, extraHttpRequestParams?: any): Observable<{}> {
return this.createWithHttpInfo(user, passwd, extraHttpRequestParams)
.map((response: Response) => {
if (response.status === 204) { <<<<<<<<<<<<<<<<<
return undefined;
} else {
return response.json();
}
});
}
/**
* User exists
*
* <strong i="10">@param</strong> user username
*/
public exists(user: string, extraHttpRequestParams?: any): Observable<boolean> {
return this.existsWithHttpInfo(user, extraHttpRequestParams)
.map((response: Response) => {
if (response.status === 204) { <<<<<<<<<<<<<<<<<<<<<
return undefined;
} else {
return response.json();
}
});
}
¿Por qué codegen solo verifica si response.status === 204
? ¿Qué pasa con otros códigos de error?
Mi definición de arrogancia es como:
<strong i="16">@PUT</strong>
@ApiOperation(value = "Add user")
@ApiResponses(value = {
@ApiResponse(code = 400, message = "Specified 'username' already exists on Living Commty."),
@ApiResponse(code = 401, message = "Specified 'username' has no a valid mail form."),
@ApiResponse(code = 402, message = "Specified 'passwd' is too short.")
})
public abstract Response create(...
<strong i="17">@GET</strong>
@ApiOperation(value = "User exists", response = Boolean.class)
@ApiResponses(value = {
@ApiResponse(code = 400, message = "Invalid user information specified")
})
public abstract Response exists(
2.2.3-INSTANTÁNEA
swagger: '2.0'
info:
description: desc
version: 1.0.2
title: Living API
termsOfService: 'http://swagger.io/terms/'
contact:
name: [email protected]
license:
name: Apache 2.0
url: 'http://www.apache.org/licenses/LICENSE-2.0.html'
host: localhost
basePath: /commty/cmng
tags:
- name: users
schemes:
- http
paths:
/users:
get:
tags:
- users
summary: User exists
description: ''
operationId: exists
produces:
- application/json
parameters:
- name: user
in: header
description: username
required: true
type: string
responses:
'200':
description: successful operation
schema:
type: boolean
'400':
description: Invalid user information specified
put:
tags:
- users
summary: Add user
description: ''
operationId: create
produces:
- application/json
parameters:
- name: user
in: header
description: username
required: true
type: string
- name: passwd
in: header
description: passwd
required: true
type: string
responses:
'400':
description: Invalid user information specified
java -jar ". \ swagger-codegen-cli \ target \ swagger-codegen-cli.jar" generate -i http: // localhost : 8082 / commty / cmng / swagger.json -l mecanografiado-angular2 -v
@jeusdi El código de estado HTTP 204 significa "sin contenido" (ref: https://httpstatuses.com/204), lo que explica por qué se devuelve undefined
.
@ wing328 Mi pregunta era: ¿Por qué codegen solo se ocupa de un tipo de respuesta de error en lugar de tomar @ApiResponses
contenido de anotación?
@ApiResponses (valor = {
@ApiResponse (código = 400, mensaje = "El 'nombre de usuario' especificado ya existe en Living Commty."),
@ApiResponse (código = 401, mensaje = "El 'nombre de usuario' especificado no tiene un formulario de correo válido."),
@ApiResponse (código = 402, mensaje = "La 'contraseña' especificada es demasiado corta.")
})
Además, ¿qué pasa con las excepciones lanzadas por los métodos create
y exists
:
@Path(value = "/users")
@Produces({"application/json"})
@Api(value = "/users")
public interface IUserCommtyEndpoint {
<strong i="16">@PUT</strong>
@ApiOperation(value = "Add user")
@ApiResponses(value = {
@ApiResponse(code = 400, message = "Specified 'username' already exists on Living Commty."),
@ApiResponse(code = 401, message = "Specified 'username' has no a valid mail form."),
@ApiResponse(code = 402, message = "Specified 'passwd' is too short.")
})
public abstract Response create(
@HeaderParam("user")
@ApiParam(value = "username", required = true)
@NotNull(message = "user.username.notnull")
@Pattern(regexp="[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?", message="{user.username.email}")
String username,
@HeaderParam("passwd")
@ApiParam(value = "passwd", required = true)
@NotNull(message = "user.passwd.notnull")
@Size(min = 6, max = 20, message = "{username.passwd.size}")
String passwd
) throws UsernameAlreadyExistsCommtyException, RepositorySystemException;
<strong i="17">@GET</strong>
@ApiOperation(value = "User exists", response = Boolean.class)
@ApiResponses(value = {
@ApiResponse(code = 400, message = "Invalid user information specified")
})
public abstract Response exists(
@HeaderParam("user")
@ApiParam(value = "username", required = true)
@NotNull(message = "user.username.notnull")
@Pattern(regexp="[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?", message="{user.username.email}")
String username
);
}
Estas excepciones son UsernameAlreadyExistsCommtyException
, RepositorySystemException
, javax.validation.ValidationException
. Todos ellos son manejados por mapeadores JAXRS. Por ejemplo:
<strong i="24">@Provider</strong>
public class CommtyExceptionMapper implements ExceptionMapper<UsernameAlreadyExistsCommtyException> {
<strong i="25">@Override</strong>
public Response toResponse(UsernameAlreadyExistsCommtyException exception) {
return Response
.status(Response.Status.BAD_REQUEST.getStatusCode())
.type(MediaType.APPLICATION_JSON)
.entity(ErrorMessage.create(exception.getCode(), exception.getMessage()))
.build();
}
}
Como puede ver, estoy incrustando un ErrorMessage {code, message}
en el cuerpo, y me gustaría manejarlos en el código typescript\angular2
...
¿Algún enfoque para manejar eso?
Me encontré con el problema de que quiero recuperar el status
de la respuesta. Más específicamente, me gustaría saber cuándo se recuperó el 401. No puedo determinar esto por el cuerpo. Este problema parecía coincidir con mi problema.
Solo para tener en cuenta, esto no se trata solo de errores, ya que 204 no es un error, sino de acceder a la respuesta. La distinción se puede hacer usando el código de estado de la respuesta. Para seguir haciendo esto fuertemente tipado, me gustaría sugerir lo siguiente:
¿No sería más correcto generar InlineBody200
además de InlineResponse200
? InlineBody200
representa el esquema y InlineResponse200
es la respuesta en sí.
La respuesta en sí es como Reponse
de angular2, excepto que su .json()
devuelve InlineBody200
.
Además se puede generar un tipo que es una unión de las posibles respuestas:
type InlineResponse = InlineResponse200 | InlineResponse401 | etc
La llamada en DefaultApi
puede devolver un Observable<InlineResponse>
.
Estas funciones devuelven un InlineResponse200 | InlineResponse401 | etc
.
De esa manera, tendrías toda la información que proporciona angular2, pero aún está fuertemente tipada.