REST y URI de almacenamiento en caché

Question

A mi entender, el uso de un servicio web REST, no se supone que un cliente saber nada de servidor de diseño URI a excepción de un par de puntos de entrada conocidos. Esto se supone para permitir que el servidor para controlar su propio espacio de URI y reducir el acoplamiento con el cliente.

Cuando un cliente para el servicio envía una solicitud exitosa para crear un nuevo recurso, el servicio responde 201 crea y se da la URI en el que el nuevo recurso se puede acceder en el campo Ubicación de cabecera.

Hay que dejar que un cliente para almacenar este URI para permitir el acceso directo al recurso en el futuro y si es así ¿por cuánto tiempo? Si URI se almacenan en caché por el cliente, esto parece ser la creación de una situación en la que cada vez que el servidor cambia su diseño URI, que tendrá que asegurarse de que una redirección permanente se sirvió cuando se accede a los URI de edad. De lo contrario el cliente rompe. Durante varios años, este sistema de redirecciones podría ir de las manos.

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

Hay una gran cantidad de información disponible acerca de las representaciones de almacenamiento en caché, pero ¿qué pasa con los URI de almacenamiento en caché en los sistemas de hipertexto REST impulsado?

Answer 1

Recuerde que Tim Berners-Lee dijo, "URL fresco no cambian". Una vez que el servidor reparte un URI al cliente, ahora es el trabajo del servidor para mantener el URI de trabajo en el futuro (por ejemplo) el envío de un Movido permanentemente la respuesta en caso de que el URI cambió y alguien pide al anterior.

Esto es en realidad lo que anima a muchos a diseñar opaca URI, como basada en identificadores de bases de datos o marcas de tiempo, en lugar de utilizar una cierta característica legible por humanos del recurso en el URI. Cualquier cosa que la gente entienda, que va a querer cambiar.

Answer 2

Si el cliente debe permitir almacenar el URI. Durante el tiempo que quiera. Como se mencionó Licky un cliente inteligente puede utilizar una respuesta Movido permanentemente para actualizar sus marcadores.

Si se piensa en ello, tenemos la mejor situación posible. Puede cambiar las direcciones URL en el servidor, mientras que la elección todavía apoyar a los clientes viejos durante el tiempo que elegimos, y los clientes inteligentes puede actualizar con eficacia automática a las nuevas direcciones URL.

¿Cuánto tiempo decide seguir apoyando esas viejas direcciones URL es realmente una decisión que debe ser hecha en base a los clientes existentes y la facilidad con la que pueden ser mantenidas.

Para mí esto es una gran mejora con respecto a los problemas de versiones con interfaces de estilo RPC.

Answer 3

Sé que esto es una vieja pregunta, pero creo que hay un subcomponente a las respuestas que veo aquí que no ha sido abordado.

Recuerde que usted no está trayendo el recurso desde el servidor, pero se están recuperando de una representación de un recurso. El recurso en sí mismo puede tener su cambio identificador primario, o se vuelven a ubicar, o lo que sea, pero la representación que se devuelve al cliente en la creación de recursos puede (o no ser) válida independientemente; todo es una cuestión de situación.

A modo de ejemplo, consideremos un sistema de carga de contenido moderado; un usuario puede tener la posibilidad de cargar el contenido para su examen por los moderadores que pueden llegar a causar que el contenido sea expuesto a una audiencia / mercado más amplio. En la carga inicial, el servidor puede responder con un URI que dirige a (por ejemplo) "usuarios / {id de usuario} / subida / {} Content ID" para que la representación de ese contenido. En algún momento, los moderadores pueden decidir promover el contenido a una "primera página"; que la representación del contenido puede ser entonces disponibles en el URI de "contenido / {contentid}"; eso no debería impedir que el usuario que subió el acceso a sus datos a "usuarios / {id de usuario} / subida / {} ContentID"; nada dice que es necesario que haya una redirección permanente, y de hecho, hay una buena razón para no ser; si el usuario decide que quiere eliminar el contenido, que debe ser capaz de realizar una supresión en el contenido; es probable que sea mucho más preferencial que los usuarios hacer eliminaciones a las representaciones de contenido desde sus propios lugares "subidos". Sin embargo, si las condiciones del sitio indican que los derechos de los usuarios al contenido subido son revocados (raro) que podría tener sentido para que el proceso de promoción de la moderación elimina de manera efectiva el contenido de la propia área del usuario, causando un "movimiento permanente".

Es realmente depende por completo de la situación específica; la validez de un URI en caché es completamente dependiente de las políticas del servidor. Al menos, yo creo que una solicitud a un URI no válido (que puede haber sido previamente válida) debería provocar una respuesta (en consonancia con HATEOAS) que puede permitir al cliente a "redescubrir" el recurso (representación) que buscaban ; al menos, un enlace a la de punto de entrada.

Answer 4

Dado que uno de los principales del resto es que los recursos son direccionables, parece perfectamente aceptable para un cliente para realizar un seguimiento de la dirección (URI) de un recurso dado. URI del recurso debe ser uno de los "puntos conocidos de entrada" que se ha referido.