En los servicios web RESTful, ¿los DTO de respuesta deben contener sus DTO secundarios?

Question

Considere un usuario (/ users/{id}) que tiene un nombre y varias ubicaciones (/ users/{id}/locations).

Cuando solicito un usuario (/ usuario/{id}), ¿ese usuario debe estar representado por completo (su identificación, nombre y ubicación) o las ubicaciones solo deben devolverse en una solicitud por separado? Por ejemplo, qué JSON DTO esperaría en una solicitud de usuario con id = 123 (/ users/123):

1) {"id": 123, "nombre": "Peter", "ubicaciones": [{"id": 1, "nombre": "Chicago"}, {"id": 2, "nombre": "Nueva York"}]}

2) {"id": 123, "name ":" Peter "," ubicaciones ": [{" id ": 1}, {" id ": 2}]}

3) {" id ": 123," nombre ":" Peter "," ubicaciones ": [1, 2]}

4) { "id": 123, "name":" Peter"}

esto es más subjetiva, empujar y tirar entre el tamaño de los DTO y las solicitudes requeridas en el caso de uso típico? Me inclino a simplemente incluir todos los datos relevantes (1), pero no estoy seguro de que sea mejor que solo requerir que los desarrolladores realicen múltiples llamadas a una API para obtener todos los de los datos que realmente desean.

Answer 1

Ser REST no necesariamente tiene que devolver la representación completa del recurso Sin embargo, desea habilitar hypermedia como medio para obtener/configurar toda la información que el usuario de su API necesita (Hypermedia como motor del estado de la aplicación - aka HATEOAS)

Para satisfacer esto, puede usar la sugerencia de @bowmanb para p Utilice un URI para todas las ubicaciones o agregue URI individuales para cada una de las ubicaciones. Probablemente desee agregar URI adicionales para otras opciones de hacer algo con el recurso.

Hay un buen artículo sobre HATEOAS por Jim Webber, Savas Parastatidis & Ian Robinson llama "how to GET a cup of coffee"

Answer 2

Soy un novato en este mundo, pero estoy construyendo una API apta y enfrentando exactamente el mismo problema. Mi trabajo inicial ha sido incluir todo, por lo que mis resultados se ven como su opción (1). De hecho, voy un poco más allá e incluí un URI con cada objeto para que, en teoría, la respuesta pueda ser navegada por un cliente suficientemente inteligente.

Habiendo dicho eso, he encontrado que un atributo en particular de mi equivalente a su objeto "usuario" es enorme. No parece afectar el rendimiento, pero me parece que ningún cliente querría toda esa información sobre ese atributo en particular; la mayoría de los clientes solo querrían el id y el nombre. Por lo tanto, voy a modificar mi enfoque predeterminado para ese atributo.

En pocas palabras, en mi opinión de novato, la decisión depende del uso previsto de sus clientes: ¿qué querría ver el cliente?

Answer 3

Debe haber alguna manera para que un cliente determine cómo encontrar las ubicaciones de un usuario. Por lo que descartaría el número 4.

Si usted está preocupado por el tamaño de su respuesta, creo que aún sería REST para incluir sólo el URI para ubicaciones de un usuario:

{ "id":123, "name":"Peter", "locations":"https://stackoverflow.com/users/123/locations" }