REST Diseño de API: consulta de datos de correo electrónico: ¿qué veneno elegir?

Question

Actualmente estamos diseñando una API REST interna. tenemos el siguiente caso de uso:

1. un usuario (109) quiere leer un mensaje que ha enviado a otro usuario (110)
2. el usuario de lectura (109) que se conoce a la aplicación a través de su ficha credenciales que recibió después de la autenticación (mientras se hace la petición GET)
3. asumimos en este ejemplo el usuario 109 era el remitente y 110 del receptor

para resumir desde la perspectiva de los usuarios "me dan el correo que i (109) han enviado a 110 "

los siguientes URI vino a la mente, pero no podemos decidir cuál tomar:

a) GET http://localhost:9099/api/mails/109?receiverUserId=110 
b) GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110 
c) GET http://localhost:9099/api/mails?receiverUserId=110 
d) GET http://localhost:9099/api/mails/me/to/110 (when logged in as 109 via token credentials we know that "me" is 109) 
f) GET http://localhost:9099/api/mails/109/to/110 (explicit request, e.g. for admins … has to be guarded against illegal access) 

todos los enlaces son "sensibles al contexto" que está enviando uno de los enlaces al receptor (110) se producir resultados diferentes al ejecutar la solicitud GET.

me gustaría saber su opinión sobre qué URL utilizar.

cualquier ayuda muy apreciada.

aplausos Marcel

Answer 1

Las diferentes respuestas a los diferentes clientes, por misma URL está bien.

StackExchange lo hace:

GET /me/comments/{toid} 

que está documentado here.

Twitter hace también:

GET /statuses/home_timeline 

que está documentado here.

Ambas direcciones URL inferir el usuario conectado en función de la autenticación. Sí, se frustra el almacenamiento en caché si los usuarios comparten un caché, pero IMO, está bien. Si esto rompe o no la restricción de "identificación de recursos" de REST es probablemente discutible. La respuesta a la pregunta this, y un comentario posterior allí me muestra por qué es discutible.

De hecho, entre las opciones, se hace URL mencionar que no son 'sensibles al contexto':

GET /api/mails?senderUserId=109&receiverUserId=110 

Ésta siempre devuelve los mensajes de 109 a 110. Sin embargo, mientras un cliente querría ver este resultado al ver los mensajes 'enviados', el otro querría ver este resultado al ver los mensajes 'recibidos'. Algo raro, ¿eh? Además, en el servidor deberá verificar que el usuario autenticado sea 109 | 110, sino arrojar un 401 UNAUTHORIZED.

Me gustaría ir con algo como:

GET /mail/sent 

declaraciones de todos los mensajes enviados.Y:

GET /mail/sent?to=110 (like applying a 'filter' to /mail/sent) 
OR 
GET /mail/sent/110 (clean URL) 

rendimientos electrónico enviado a 110.

Answer 2

"sensibles al contexto" enlaces son mala idea para un API REST (en particular, esto dificulta el almacenamiento en caché). Si solo quieres usar HTTP, esto está bien.

Así que sugeriría utilizar URL que no dependen del usuario actual y limitar el acceso a ellas de acuerdo con sus reglas.

Answer 3

En mi opinión, se necesitan de 2 capas:

Una de ellas es la capa interna, que no requiere autenticación de usuario, sólo es accesible desde los componentes internos. Incluye APIs como

GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110

La ventaja de esta capa es la capacidad de prueba, reutilización y cachability.

La otra capa es la capa externa, que requiere autenticación de usuario y es accesible desde clientes externos. Incluye API como

GET http://localhost:9099/api/mails?receiverUserId=110.

Los clientes deben iniciar sesión para obtener las credenciales del token, el servidor puede obtener la información del usuario de este token y asignar la llamada API externa a la llamada API interna.

Puede tener diferentes tipos de métodos de autenticación, pero la capa interna no se cambiará, solo necesita asignar capas externas diferentes a la capa interna.