¿Debo dividir mi API por tipo de usuario?

7

Digamos que tengo una aplicación para gestionar equipos deportivos. Los usuarios potenciales tienen un rol de 'entrenador', 'jugador' y 'fan'. En muchos casos, tendrán que hacer llamadas de api similares para recuperar información como esta:

/api/v1/players    (retrieve all players on their current team)
/api/v1/events     (retrieve all events for their current team)

En otros casos, los roles pueden tener ciertas funciones solo disponibles para ellos, como esta:

/api/v1/opposing_players/:opposing_player_id  (retrieve scouting info about an opposing player, not available to fans)

Mi pregunta se reduce a ... ¿Debo separar explícitamente los apis con un prefijo para cada rol? ¿O debería la API tener solo una URL base?

/api/v1/coaches/events
/api/v1/fans/events
/api/v1/players/events

o

/api/v1/events
    
pregunta Msencenb 28.07.2017 - 18:03

1 respuesta

11

No, no debes usar el nivel de acceso como parte de la URI.

Ya existe una forma estándar de separar la API por acceso de usuario, y eso es con autorización. Todos los usuarios deben acceder a los mismos puntos finales y, en función de la función o los atributos del usuario autenticado, puede

  • Devolver 401 no autorizado: si el usuario no está autenticado
  • Devolver 403 Prohibido: si el usuario no tiene el rol o los atributos adecuados para acceder a un recurso
  • Devuelve diferentes modelos según el nivel de acceso. P.ej. Se le puede permitir al entrenador ver la fecha de nacimiento de cada jugador, pero los fanáticos no están autorizados. puede mostrar / ocultar los atributos de los modelos según el acceso.

Si hiciste el uso de un esquema de API por separado para cada función, aquí hay algunos inconvenientes:

  • ¿Cómo representa a la API que son iguales para todos los roles?
  • Debe duplicar muchas rutas cuando se agrega un nuevo rol (por ejemplo, rol de administrador del sistema o administrador de división)
  • ¿Cambiar el nombre de un rol romperá la API?
  • No intuitivo: si soy un entrenador pero quiero acceder a los datos del jugador, creo que debería acceder a /api/v1/players , pero realmente necesito acceder a /api/v1/coaches/players o algo así.
  • ¿Cómo representan a los clientes que son jugadores y aficionados? Es decir. múltiples roles
  • ¿Cómo admite el hecho de permitir clientes no autenticados? Es decir. no hay roles
  • Datos redundantes: debe verificar que cada usuario esté autorizado para acceder a un recurso, pero ahora también debe verificar que la función del usuario coincida con el URI. Debe controlar el caso límite cuando el rol del usuario no coincide con el rol del URI.
  • Cambiar la autorización es un cambio que rompe la interfaz. Digamos que un entrenador se retira y se convierte en un fan. Ahora deben cambiar todos los puntos finales a los que solían acceder.
respondido por el Samuel 29.07.2017 - 03:33

Lea otras preguntas en las etiquetas