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

150
Vistas
Is using Object class to represent all kind of Json payload a good idea

I am currently working in a code base where for every REST API response they use a java class like below

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

The problem is, when we refer to the swagger documentation of the REST APIs it shows a json structure like below.

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

}

So the response will have payload if response is success, error list in case of errors and response status set to success or failure respectively.

  1. Is it a good practice to use same json structure for error and success?
  2. Is there any way to improve swagger documentation, so that I can show what the response payload json will look like for a particular API response.

EDIT: I just want to mention that I cannot change the response payload to any thing else, as it is being used in more than 1000 APIs and is distributed into different services.

Is there any way to improve at least the swagger documentation, without changing the Response Object in java, because that ship has sailed a long time ago.

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

0

  1. It is not a good practice to use the same json structure for error and success responses.
  2. Yes, if you have control over the Swagger definitions, you can specify different responses per response code.

Here is an example from the Swagger documentation

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

you can use ResponseEntity<? extends Response> return type in your methods. so that if response is success, both of them returned, as well as response is 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