Almacenamiento en memoria caché REST y URI

Question

Según tengo entendido, utilizando un servicio web RESTful hypertext-driven, se supone que un cliente no debe saber nada sobre el diseño del URI del servidor, excepto por un par de puntos de entrada conocidos. Se supone que esto permite que el servidor controle su propio espacio de URI y reduzca el acoplamiento con el cliente.

Cuando un cliente del servicio envía una solicitud satisfactoria para crear un nuevo recurso, el servicio responde 201 CREATED y proporciona el URI al que se puede acceder al nuevo recurso en el campo de encabezado Ubicación.

¿Debería un cliente tener permitido almacenar este URI para habilitar el acceso directo al recurso en el futuro y, de ser así, durante cuánto tiempo? Si el cliente almacena en caché los URI, esto parece estar configurando una situación en la que cada vez que el servidor cambia su diseño de URI, deberá asegurarse de que se atienda un redireccionamiento permanente cuando se acceda a los URI antiguos. De lo contrario, el cliente se rompe. Durante varios años, este sistema de redirecciones podría salirse de control.

Esta situación no parece haber dado al servidor mucho más control sobre su espacio URI que un enfoque híbrido REST-RPC utilizando plantillas URI.

Hay mucha información disponible acerca de las representaciones de almacenamiento en caché, pero ¿qué ocurre con el almacenamiento en caché de URI en sistemas RESTful basados ​​en hipertexto?

Answer 1

Recuerda que Tim Berners-Lee dijo, "las URL geniales no cambian". Una vez que el servidor entrega un URI al cliente, ahora es tarea del servidor mantener el URI funcionando en el futuro (por ejemplo) enviando una respuesta Moved-Permanently en caso de que el URI cambie y alguien solicite el anterior.

Esto es lo que alienta a muchos a diseñar URI opacos, como los basados ​​en identificadores de base de datos o marcas de tiempo, en lugar de utilizar alguna propiedad del recurso que pueda leerse en el URI. Cualquier cosa que la gente entienda, ellos querrán cambiar.

Answer 2

Dado que uno de los principios de REST es que los recursos son direccionables, parece perfectamente aceptable que un cliente realice un seguimiento de la dirección (URI) de un recurso determinado. Los URI de recursos deben ser uno de los "puntos de entrada conocidos" a los que se refiere.

Answer 3

Sí, el cliente debe poder almacenar el URI. Por el tiempo que quiera. Como mencionó Licky, un cliente inteligente puede usar una respuesta Moved-Permanently para actualizar sus marcadores.

Si lo piensas bien, tenemos la mejor situación posible. Puede cambiar las direcciones URL en el servidor, mientras elige seguir brindando soporte a clientes antiguos durante el tiempo que nosotros decidamos, y los clientes inteligentes pueden autoactualizarse efectivamente a las nuevas URL.

El tiempo que elija para continuar admitiendo esas URLs antiguas es realmente una decisión que debe tomarse en función de los clientes existentes y la facilidad con la que pueden mantenerse.

Para mí, esta es una gran mejora sobre los problemas de versionado con las interfaces de estilo RPC.

Answer 4

Sé que esta es una vieja pregunta, pero creo que hay un subcomponente de las respuestas que veo aquí que no se ha abordado.

Recuerde que no está recuperando el recurso del servidor, pero está recuperando una REPRESENTACIÓN de un recurso. El recurso en sí puede tener su identificador primario cambiar, o ser reubicado, o lo que sea, pero la representación que se devolvió al cliente en la creación de recursos puede (o no) ser válida independientemente; es todo una cuestión de situación.

Como ejemplo, considere un sistema de carga de contenido moderado; un usuario puede tener la capacidad de cargar contenido para que lo consideren los moderadores que eventualmente puede causar que el contenido se exponga a un público/mercado más amplio. En la carga inicial, el servidor puede responder con un URI que dirige (por ejemplo) "users/{userid}/upload/{contentid}" para esa representación de ese contenido. En algún momento, los moderadores pueden decidir promocionar el contenido a una "página de inicio"; esa representación del contenido puede estar disponible en el URI de "content/{contentid}"; eso no debería impedir que el cargador original acceda a sus datos en "users/{userid}/upload/{contentid}"; nada dice que debe haber una redirección permanente, y de hecho, hay una buena razón para que no exista; si el usuario decide que quiere eliminar el contenido, debería poder realizar un DELETE sobre el contenido; probablemente sea mucho más preferente que los usuarios hagan DELETE a las representaciones de contenido desde sus propias ubicaciones "cargadas". Sin embargo, si los términos del sitio indican que los derechos de usuario para el contenido subido son revocados (no poco común) podría tener sentido que el proceso de promoción de moderación elimine efectivamente el contenido del área del usuario, causando un "movimiento permanente".

Depende totalmente de la situación específica; la validez de un URI almacenado en caché depende completamente de las políticas del servidor. Al menos, creo que una solicitud a un URI no válido (que puede haber sido previamente válido) debería provocar una respuesta (coherente con HATEOAS) que pueda permitir al cliente "redescubrir" el recurso (representación) que estaba buscando. ; al menos, un enlace al punto de entrada.