API - Múltiples peticiones vs separación de las funciones de usuario

Question

Yo estoy trabajando en el frontend de una sola página de la aplicación y tengo que lista un número de estudiantes.Cada estudiante está conectado a una cierta user_id Esto es lo que la API devuelve para todas las funciones de usuario (superadmin, administrador, profesor, estudiante) al realizar la GET /students:

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
}

Yo estoy trabajando en el superadmin papel en el momento en el que estoy en la necesidad de datos adicionales de cada estudiante (subscription_type), que sólo está disponible en GET /users/:id

Así que cuando estoy listado de 20-30 estudiantes en una página a través de GET /students/, con el fin de obtener la subscription_type, También tendrás que hacer 20-30 solicitudes adicionales, uno para cada estudiante.

Hablé con el API de chico acerca de esto y me dijeron que la inclusión de los datos adicionales en students "no es el Descanso manera de hacerlo", "va a ralentizar los tiempos de respuesta aún más" y que "el 30 de solicitudes adicionales pesan menos que un pedazo grande".

No sé nada acerca de cómo trabajar en una API, así que realmente no puedo opinar, pero estoy loco para pensar que 30 de las solicitudes de carga de la página es absurdo?

Así que lo próximo?¿Debo seguir adelante y realizar las solicitudes adicionales?Debe separar las respuestas para cada rol de usuario e incluir sólo las cosas que se necesitan para cada rol?¿Cuál es la forma correcta de esta gestión?

Answer 1

Aunque estrictamente hablando la API chico es correcta, tras el Descanso del evangelio de manera demasiado estricta puede conducir a ineficiencias, como el 1+N problema creado por los puristas de la aplicación.Un concepto clave en el Descanso de diseño es que los recursos no tienen que asignar directamente a los objetos de dominio.Cuando el diseño de recursos se debe mirar a los escenarios de uso.En el super admin escenario, suena como cuando el cliente solicita una colección de students y también normalmente o siempre las necesidades de datos de users, específicamente subscription_type.El modelo de objetos es claramente normalizado como debe ser, pero eso no quiere decir que los recursos deben ser, o debe ser siempre.

Hay un par de diferentes patrones que he utilizado para hacer escenarios similares más eficiente.Que (si) aplicar depende de cómo los recursos son consumidos por los clientes.

Compuesto De Recursos

Esta es la combinación de todas o parte de dos o más objetos de dominio (por ejemplo, student y user) en un solo recurso.

Dado que todos los students presumiblemente son también users, usted puede incluir la totalidad o parte de los datos de usuario en el estudiante de recursos, según corresponda.

GET /students

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
  subscription_type: "foo"
}

Recursos Relacionados

(Similar a otra respuesta) Esta es una técnica donde el cliente puede indicar que se quiere un recurso relacionado incluidos en la respuesta.Esto es particularmente útil en el "tiene" un tipo de relación en el modelo de dominio.Esto permite que el cliente esencialmente la carga perezosa o con ganas de carga el recurso.

GET /students

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
}

GET /students?include_user=true

{
  address: null
  class_id: 184
  class_name: "I B"
  date_of_birth: null
  first_name: "first"
  gender: null
  grade: 1
  id: 192
  last_name: "last"
  nationality: null
  place_of_birth: null
  ranking_by_class: 0
  ranking_by_school: 0
  registration_number: null
  user_id: 238
  user:
  {
   id: 238
   subscription_type: "foo"
   ...
  }
}

Answer 2

Tienes dos temas aquí, que no deberían estar atados juntos. Uno son los datos devueltos para cada usuario para la convocatoria de índice (/ estudiantes), y el otro es el proceso de autorización que debe determinar en qué datos se puede exponer un determinado usuario.

Con respecto al problema de los datos, no creo que haya una regla específica a seguir. Depende totalmente de los requisitos de su aplicación. Si el campo de suscripción_type suele ser innecesario, puede considerar pasar un parámetro de consulta ('inclems_extra_data= 1', por ejemplo) para indicar que lo necesita en la solicitud específica, donde de forma predeterminada no será devuelta.

Con respecto al problema de la autorización, esto debería estar totalmente desconectado de los datos que solicita su solicitud. El servidor debe poder determinar qué datos son visibles para el usuario de acuerdo con la ID de usuario. (Puede consultar el Cancan GEM] [1] como una posible solución).

Entonces, combinando las dos cuestiones, cualquier tipo de usuario debe poder hacer que la solicitud "/ estudiantes" con o sin la bandera 'inclusión_extra_data'. Si el servidor encuentra al usuario no autorizado para ver los datos adicionales, puede elegir una de las 2 opciones: devolver solo los datos que el usuario puede ver, o devolver una respuesta '401 no autorizada'.

Ambas formas son válidas y afectan la forma en que se ocupa de la respuesta en la aplicación de su cliente. (I, personalmente, prefiero lo más tarde, ya que es más descriptivo para el cliente).

Espero que esto ayude :)