Devo especificar o userId na estrutura da URL REST?

9

Basicamente, um recurso do meu aplicativo é recuperar os amigos do usuário conectado.

Na verdade, hesito entre os dois tipos de terminais:

GET / api / usuários / amigos
GET / api / users /: userId / friends

Usando 1, userIdseria acessível através do token de autenticação.
Usando 2, o servidor precisaria verificar adicionalmente a correspondência entre o passado userIde o ID do usuário registrado especificado no token de autenticação, para evitar qualquer acesso malicioso a outros dados do usuário, como amigos.

Portanto, devo ser suficiente, mas não parece um URL de descanso padrão.

O que é uma boa prática?

— Mik378
fonte

7

A primeira solução tem o benefício de evitar a duplicação de dados. A solicitação significa claramente:

Olá, eu sou o John. Me dê a lista dos meus amigos.

Se possível, eu até o encurtaria GET /api/friends.

Por outro lado, se você espera acessar amigos de outros usuários, a segunda solução parece boa. O pedido significa:

Olá, eu sou o John. Me dê a lista de amigos de John.

mas também pode ser:

Olá, eu sou o John. Me dê a lista de amigos de Mary.

Por exemplo, uma situação em que essa mudança é possível é onde uma pessoa pode encontrar seus próprios amigos, mas também amigos de seus amigos.

— Arseni Mourzenko
fonte

Resposta pura, obrigado. Você apenas confirmou o que eu pensava;)

— Mik378

Eu daria um passo adiante. Com GET /api/friendseu iria renomeá-lo GET /api/myFriends. Do ponto de vista da descoberta, é mais auto-documentado. Além disso, com o REST, é útil pensar em como um cache de navegador / proxy lidaria com isso. Com GET /api/myFriendsisso, é perfeitamente possível ter um erro em que você exibe os amigos errados devido ao cache.

— ArTs

Há um problema quando você usa URIs relativos (em relação ao usuário conectado), certos cenários se tornam difíceis de implementar. Especialmente quando você deseja permitir que um usuário represente outro, como um usuário de suporte que precisa fazer login e ver tudo como outro usuário. Se ele estiver logado como usuário de suporte, mas tentar se passar por um usuário que ele quer ajudar, ele acabará olhando para seus próprios amigos, não para o usuário que ele está tentando ajudar.

— Jbm

3

As APIs de repouso devem ser guiadas por hipertexto! Como você clicaria de um link para outro em uma página html padrão.

Um URL é um identificador exclusivo para um recurso. Ter um URL representando mais de um recurso está em total desacordo com o ReST.

Com seu exemplo, o seguinte URL:

/api/users/:userId

deve ter um link em sua resposta ao: userId friends url

A dissertação de Roy Fielding contém um conjunto de restrições necessárias para cumprir o 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
fonte