Por ejemplo, si llamo a GET para obtener un artículo, lo elimino con DELETE y lo OBTENGO nuevamente, ¿cómo debería funcionar el segundo GET?¿Cómo manejar los datos obsoletos en REST?
Es decir, siguiendo correctamente los principios de REST, ¿cuál es el enfoque correcto al hacer esto, ya que GET puede almacenarse en caché y todo? ¿Cuál es el enfoque para manejar datos obsoletos en REST?
En primer lugar, el comportamiento depende de lo que devolvió la llamada DELETE como su código de respuesta.
Si DELETE devuelve 200 - OK o 204 - No Content, el cliente debería obtener 404 - Not Found en su siguiente llamada a GET. Eso es porque 202 y 204 significan que el recurso se eliminó de inmediato.
Sin embargo, si DELETE devuelve 202 - Accepted, existe la posibilidad de que el cliente pueda OBTENER el recurso con éxito durante algún tiempo después. Esto se debe a que 202 significa que el recurso ha sido marcado para su eliminación, pero no necesariamente se limpia de inmediato.
En segundo lugar, si hay un caché involucrado, el comportamiento se debe construir para ser coherente con lo que sucedería si no hubiera caché presente. Un DELETE exitoso siempre debe conducir a una eliminación tanto del origen verdadero de los datos como de cualquier copia en caché.
Como se estableció originalmente, un GET después de un DELETE debería producir un error HTTP 404 independientemente del almacenamiento en caché que pueda existir. El código lógico debe ser lo suficientemente inteligente como para eliminar el registro de la tienda persistente, así como la memoria o la memoria caché en memoria. Además, la interfaz de usuario debe poder manejar el resultado del 404 con el flujo o proceso que considere apropiado.
Si acaba de eliminar el elemento, ¿por qué tratará de "obtenerlo" de nuevo? No existirá. Tal vez me estoy perdiendo algo o la pregunta no estaba clara. –
@Brent Pabst: Considere por ejemplo enlaces en una aplicación de interfaz de usuario donde la eliminación ocurre en una ventana emergente pero el enlace GET está en la página de apertura y no se actualiza o transfiere por correo y el usuario los inserta en la barra de direcciones del navegador directamente en el medio el borrado, etc. ¡Esto está sujeto a la caché! La idea es, si el artículo ya no está, cómo debería funcionar el OBTENIDO. ¿Deshabilitar TODA la caché? ¿Es aceptable tener algo de caché? ¿Cuál es el enfoque de REST para todo esto? – JohnDoDo
El segundo GET devolverá naturalmente el código HTTP '404 Not Found'. El almacenamiento en caché es un asunto completamente diferente para el cual proporcionaré la respuesta maravillosamente opaca: "depende". Pero si hay * un * segundo GET, parece bastante obvio que estaría produciendo un 404? –