¿Debería un URI dado en una arquitectura RESTful devolver siempre la misma respuesta?

Question

Esta es una especie de pregunta de seguimiento a this one.

Por lo tanto, ¿está teniendo una respuesta única para un URI dado un inquilino principal de la arquitectura RESTful? Mucha discusión aquí tiende a esa dirección, pero no la he visto en ninguna parte como una regla "dura y rápida".

Entiendo el valor de esto (para almacenar en caché, rastrear, pasar enlaces, etc.), pero también veo cosas como que la API de Twitter lo viola (Una solicitud a http://api.twitter.com/1/statuses/friends_timeline.xml variará en función del nombre de usuario dado), y entiendo hay momentos en que puede ser necesario, sin mencionar que un recurso con paginación cronológica también cambiará a medida que se agreguen nuevos elementos.

Debería esforzarme para que se eliminen por completo las respuestas variadas del mismo URI, o simplemente acepto que a veces no es práctico, y siempre que minimice su aparición, estaré en buena forma.

Answer 1

No es la misma respuesta, sino una representación (que depende de conectores y encabezados de solicitud condicionales) del mismo recurso . En una arquitectura de descanso, un URI identifica uno y solo un recurso (pero un recurso puede tener varios URI). Presentar diferentes recursos según el usuario autorizado (siendo HTTP Auth, cookies, ...) es una mala práctica, ya que el mismo URI representa un recurso diferente para cada usuario, como en el ejemplo de Twitter. No puedo permitir que vea mi línea de tiempo y le proporcione el URI, ya que este es el mismo URI para su línea de tiempo. El usuario debe estar codificado en el URI y el acceso debe estar limitado por el mecanismo de autorización. Para tener un solo punto de acceso que presente recursos diferentes según el usuario autenticado, use un redireccionamiento (por ejemplo, 303 Consulte Otro, 302 Encontrado, ...)

Answer 2

Nada en REST dice misma respuesta - pero shuld estar preparado para manejar cosas como el "If-Modified Desde" cabeceras de petición CUANDO tienen sentido;)

La API Tritter tiene otros problemas, obviamente - como en: esta es una decisión de diseño. Una vez que permite aislar las líneas de tiempo de amigos, por ejemplo, tendría sentido colocar la línea de tiempo debajo de un elemento de nombre de amigo; obviamente decidieron no hacerlo;)

Se reduce a decisiones de diseño. Mire OData (como http://odata.netflix.com/Catalog/) - aquí hace que snse devuelva los mismos datos para cada URL por un tiempo dado (almacenamiento en caché), porque es un cataloque completamente público. Para otros escenarios, puede no tener sentido.

Answer 3

Algunas cabeceras de petición cambian lo que se devuelve (sin dejar de ser REST):

1. Es evidente que se espera que los cache-cabeceras que se utilizará para determinar si un 304 o 200 se devuelve
2. La cabecera Accept se puede usar para determinar el formato de la respuesta (HTML vs XML vs JSON)
3. El encabezado Authorized puede determinar al menos si se devuelve un 401, 403 o 200.
4. Además, se permite que los recursos cambien con el tiempo.

La verdadera pregunta es si el encabezado Authorized (que determina el usuario) puede usarse para cambiar el contenido de la respuesta. No he visto ninguna declaración oficial al respecto, pero sospecho que varias personas preferirían tener al usuario en la URL y el encabezado Authorized usado para validar el acceso. Sospecho que de cualquier forma es RESTful.