¿Debo especificar el ID de usuario en la estructura URL REST?

9

Básicamente, una característica de mi aplicación es recuperar los amigos del usuario registrado.

En realidad, dudo entre ambos tipos de puntos finales:

  1. OBTENER / api / usuarios / amigos
  2. GET / api / users /: userId / friends

Usando 1, userIdsería accesible a través del token de autenticación.
Usando 2, el servidor tendría que verificar adicionalmente la correspondencia entre el pasado userIdy el ID de usuario registrado especificado en el token de autenticación para evitar cualquier acceso malicioso a otros datos del usuario, como amigos.

Entonces 1 debería ser suficiente, pero no suena como una URL de descanso estándar.

¿Qué es una buena práctica?

rest http authentication url Mik378
fuente

Respuestas:

7

La primera solución tiene la ventaja de evitar la duplicación de datos. La solicitud simplemente significa:

Hola soy John Dame la lista de mis amigos.

Si es posible, incluso lo acortaría GET /api/friends.

Por otro lado, si espera poder acceder a amigos de otros usuarios, la segunda solución parece ser la buena. La solicitud significa:

Hola soy John Dame la lista de amigos de John.

pero también puede ser:

Hola soy John Dame la lista de amigos de Mary.

Por ejemplo, una situación en la que tal cambio puede ser posible es donde una persona puede encontrar a sus propios amigos, pero también amigos de sus amigos.

Arseni Mourzenko
fuente
Buena respuesta, gracias. Acabas de confirmar lo que pensaba;)
Mik378
Yo iría un paso más allá. Con GET /api/friendslo cambiaría de nombre GET /api/myFriends. Desde el punto de vista de la visibilidad, es más autodocumentado. Además, con REST es útil pensar cómo lo manejaría un caché de navegador / proxy. Con GET /api/myFriendsello es perfectamente posible tener un error en el que se visualizan los amigos equivocados debido al almacenamiento en caché.
ArTs
Hay una trampa cuando usa URI relativos (en relación con el usuario conectado) ciertos escenarios se vuelven difíciles de implementar. Particularmente cuando desea dejar que un usuario se haga pasar por otro, como un usuario de soporte que necesita iniciar sesión y ver todo como otro usuario. Si ha iniciado sesión como usuario de soporte, pero intenta hacerse pasar por un usuario al que quiere ayudar, terminará mirando a sus propios amigos, no al usuario al que intenta ayudar.
Jbm
3

Descanso Api debe ser impulsado por hipertexto! Como haría clic de un enlace a otro en una página html estándar.

Una URL es un identificador único para un recurso. Tener una URL que represente más de un recurso está en total desacuerdo con ReST.

Con su ejemplo, la siguiente url:

/api/users/:userId

debería tener un enlace en su respuesta a: url de amigos de userId

La disertación de Roy Fielding contiene un conjunto de restricciones necesarias para cumplir con ReST.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://fr.slideshare.net/rnewton/2013-06q-connycrestfulwebapis http: //www.ics. uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Christophe Willemsen
fuente