rest - para - java enterprise edition oracle

En JAX RS, las diferencias entre Respuesta de devolución y Frijol o Colección de frijoles(DTO)

Question

Estoy trabajando en la construcción de una API REST. Mi pregunta es, al usar Jersey, cuáles son las diferencias entre que mis servicios creen y devuelvan un objeto Response o devuelvan el bean o la colección. Solo me preocupan las llamadas exitosas, arrojo las excepciones apropiadas para errores y situaciones excepcionales.

Aquí hay un ejemplo:

@Produces(MediaType.APPLICATION_JSON)
public Response search(FooBean foo){
    List<FooBean> results = bar.search(foo);
    return Response.ok(results).build();
}

vs.

@Produces(MediaType.APPLICATION_JSON)
public List<FooBean> search(FooBean foo){
    List<FooBean> results = bar.search(foo);
    return results;
}

He visto utilizar ambos ejemplos, y preferiría el segundo escenario, solo para que sea más fácil reconocer el método de servicio. He examinado las respuestas a estos dos métodos y parecen ser idénticos.

¿Pensamientos?

Answer 1

Las diferencias se explican en la especificación JAX-RS:

3.3.3 Tipo de devolución

Los métodos de recursos PUEDEN devolver void, Response, GenericEntity u otro tipo de Java, estos tipos de retorno se asignan a un cuerpo de entidad de respuesta de la siguiente manera:

vacío
Resultados en un cuerpo de entidad vacío con un código de estado 204.

Respuesta
Resultados en un cuerpo de entidad mapeado a partir de la propiedad de la entidad de la respuesta con el código de estado especificado por la propiedad de estado de la respuesta. Un valor de retorno nulo da como resultado un código de estado de 204. Si no se establece la propiedad de estado de la respuesta: se usa un código de estado 200 para una propiedad de entidad no nula y se usa un código de estado 204 si la propiedad de la entidad es nula.

GenericEntity
Resultados en un cuerpo de entidad mapeado a partir de la propiedad Entidad de GenericEntity. Si el valor de retorno no es nulo, se usa un código de estado de 200, un valor de retorno nulo da como resultado un código de estado de 204.

Otro
Resultados en un cuerpo de entidad mapeado a partir de la clase de la instancia devuelta. Si el valor de retorno no es nulo, se usa un código de estado de 200, un valor de retorno nulo da como resultado un código de estado de 204.

Los métodos que necesitan proporcionar metadatos adicionales con una respuesta deben devolver una instancia de Respuesta , la clase ResponseBuilder proporciona una forma conveniente de crear una instancia de respuesta utilizando un patrón de generador.

Los beans "normales" se asignan de la misma manera que Response , con la excepción de que una Response permite establecer metadatos adicionales (encabezados de respuesta, estado especializado, tipo de contenido especializado, etc.). En cuanto a cuál usar, eso depende enteramente de usted también: la Response le da más flexibilidad, pero los frijoles regulares son más "auto-documentados".

Answer 2

Mi opinión personal, si la respuesta contiene DTO (Bean / Collection of beans), entonces el servicio de descanso siempre debe devolver DTO , pero no el objeto Response.

La motivación : temprano o tarde, se le pedirá que haga un uso del servicio de descanso más fácil para los clientes, proporcionando la API de cliente de descanso . Por lo general, debe extraer interfaces de reposo para implementarlas con sus servicios de descanso . Estas interfaces de reposo son utilizadas por los clientes de su cliente de descanso.

Y desde el punto de vista del cliente, existe una gran diferencia entre el procesamiento de DTO y la respuesta simple. En caso de que se use Response, su cliente se verá forzado a:

1. Verificar el código de respuesta explícitamente para procesar la respuesta exitosa
2. Manejar errores, verificando códigos explícitamente
3. Convierta el cuerpo de su respuesta en DTO solo.

Lo que significa que el manejo de la respuesta es muy similar a la devolución de los códigos de error en los métodos, lo que se considera una muy mala práctica. Para manejar los errores en un solo lugar, se usan excepciones (no estoy hablando de las formas FP de manejar errores, que es lo mejor).

Entonces, ¿qué puedes hacer?

1. En caso de que una solicitud se procese con éxito, convierta sus datos de servicio de descanso en DTO / Bean y devuélvalos.
2. En caso de que si la validación falló, o algo salió mal, lanzar una excepción en su servicio de descanso. Quizás un mapeador de excepciones predeterminado no sea bueno para usted, por lo tanto, deberá implementar su propio mapeador de excepciones.

Entonces, si piensas con anticipación, debes regresar a DTO.

Un caso de uso, cuando debería devolverse una respuesta simple, por ejemplo, cuando exporta un archivo. Parece que JAX RS no permite devolver el objeto InputStream. No estoy seguro, tiene que ser revisado.

El otro caso de uso fue apuntado por @Perception, pero es más una excepción que una regla:

Los métodos que necesitan proporcionar metadatos adicionales con una respuesta deben devolver una instancia de Respuesta, la clase ResponseBuilder proporciona una forma conveniente de crear una instancia de respuesta utilizando un patrón de generador.

Nota: es una pregunta general para JAX RS, no depende de la implementación exacta, como Resteasy o Jersey

Answer 3

No hay diferencia si desea devolver siempre la respuesta 200 - OK , capturando y manipulando todas las excepciones que pueden ocurrir antes o después de que su método devuelva el resultado, con intercepciones o WebApplicationException . Entonces, ambos métodos darán las mismas respuestas.

La única diferencia es en escenarios específicos, como devolver objetos nulos o crear objetos, como en este ejemplo:

@POST
@Consumes("application/json")
public Response post(String content) {
    URI createdUri = ...
    Object createdContent = create(content);
    return Response.created(createdUri).entity(createdContent).build();
}

En este caso, el retorno será 201 - CREATED (con el URI para acceder al objeto creado)

Entonces, el siguiente método:

@POST
@Consumes("application/json")
public Object post(String content) {
    URI createdUri = ...
    Object createdContent = create(content);
    return createdContent;
}

... devolverá una respuesta 200 - OK

Si no le importa qué estado de respuesta recibirá su cliente, puede usar cualquiera de las declaraciones sin problema.

Fuente: Jersey .