Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

147
Vistas
Es una buena idea usar la clase Object para representar todo tipo de carga útil Json

Actualmente estoy trabajando en una base de código donde para cada respuesta de la API REST usan una clase Java como la siguiente

 { Object payload; List<Error> errors; String responseStatus; }

El problema es que, cuando nos referimos a la documentación de swagger de las API REST, muestra una estructura json como la siguiente.

 { "payload":{}, "errors": [ { "errMsg":"", "errCode": "" } ], "responseStatus":"" }

Por lo tanto, la respuesta tendrá una carga útil si la respuesta es exitosa, una lista de errores en caso de errores y un estado de respuesta establecido en éxito o falla, respectivamente.

  1. ¿Es una buena práctica usar la misma estructura json para error y éxito?
  2. ¿Hay alguna forma de mejorar la documentación de swagger, de modo que pueda mostrar cómo se verá la carga de respuesta json para una respuesta de API en particular?

EDITAR : solo quiero mencionar que no puedo cambiar la carga de respuesta a ninguna otra cosa, ya que se usa en más de 1000 API y se distribuye en diferentes servicios.

¿Hay alguna forma de mejorar al menos la documentación de Swagger, sin cambiar el objeto de respuesta en Java, porque ese barco zarpó hace mucho tiempo?

over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

  1. No es una buena práctica usar la misma estructura json para las respuestas de error y éxito.
  2. Sí, si tiene control sobre las definiciones de Swagger, puede especificar diferentes respuestas por código de respuesta.

Aquí hay un ejemplo de la documentación de Swagger.

 paths: /users/{id}: get: summary: Gets a user by ID. response: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/User' '401': $ref: '#/components/responses/Unauthorized' '404': $ref: '#/components/responses/NotFound' # Descriptions of common components components: responses: NotFound: description: The specified resource was not found content: application/json: schema: $ref: '#/components/schemas/Error' Unauthorized: description: Unauthorized content: application/json: schema: $ref: '#/components/schemas/Error' schemas: # Schema for error response body Error: type: object properties: code: type: string message: type: string required: - code - message # Schema for the User response User: type: object properties: # Add properties for the User object # ...
over 4 years ago · Santiago Trujillo Denunciar

0

puedes usar ResponseEntity<? extends Response> tipo de retorno en sus métodos. de modo que si la respuesta es exitosa, ambos regresaron, así como la respuesta es un error.

 public ResponseEntity<? extends ResponseDto> foo(RequestDto request){ if(success){ return new ResponseEntity<>(new SuccessResponse(Enum.SuccessResponse.getMessage,200,dto),HttpStatus.OK); } return new ResponseEntity<>(new ErrorResponse(Enum.ErrorResponse.getMessage,400),HttpStatus.BAD_REQUEST); }
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda