restful - Práctica recomendada para implementar búsquedas de larga duración con REST
rest vs soap (5)
¿Podría esperar en lugar de una encuesta si solo quiere los resultados completos?
¿Por qué no puede proporcionar un recurso como parte de su POST que obtendrá los resultados PUT a él? Proporciona una interfaz REST de "devolución de llamada" para que, en lugar de sondear, el proceso del cliente espere un PUT para el recurso proporcionado. A continuación, puede OBTENER los resultados o los resultados se pueden incluir en el PUT.
Como parte de un servicio REST, debo implementar una búsqueda. La idea básica es que el usuario puede PUBLICAR una nueva búsqueda y OBTENER los resultados:
POST http://localhost/api/search
GET http://localhost/api/search?id=123
Sin embargo, mi búsqueda puede durar unos minutos y devolver resultados parciales hasta que finalice. Es decir, la Solicitud GET devolvería algo así como:
status: running
results: a, b, c.
mientras que la próxima solicitud GET podría regresar
status: completed
results: a, b, c, d, e.
Esto contradice la semántica de una solicitud RESTful GET. La solicitud siempre debe devolver el mismo resultado cuando se llama varias veces. Por ejemplo, cuando el usuario utiliza un proxy de almacenamiento en caché, es posible que nunca se entreguen los resultados completos al usuario.
Pregunta: ¿Hay alguna forma de proporcionar una implementación verdaderamente RESTful para búsquedas de larga ejecución con resultados parciales?
Hace unos días tuve la suerte de tropezar con una publicación de blog en reddit que se ocupa de su problema. Es posible que desee comprobarlo: RESTy long-ops de Bill Higgin .
Feliz lectura.
Mientras se está ejecutando la búsqueda, puede establecer los encabezados de respuesta apropiados (p. Ej. Expires o max-age ) para indicar que la respuesta no debe almacenarse en caché (HTTP / 1.1 14.9.3 , 13.4 ).
Una vez que se complete el resultado de la búsqueda, puede enviar un encabezado Expires / max-age más apropiado para permitir o ampliar la capacidad de almacenamiento en caché del resultado.
La carga recaería en el cliente para volver a consultar el recurso hasta que se complete su estado de búsqueda. El cliente podría quizás usar el valor del encabezado Expires para determinar cuándo debería volver a consultar los resultados actualizados.
Además de esto, también puede usar un código de estado 2XX personalizado para indicar que el resultado aún no está completo. Tal vez un HTTP/1.1 299 In Progress , o lo que sea que tenga sentido. La especificación indica que los códigos de estado HTTP son extensibles .
Para el registro, su declaración:
Esto contradice la semántica de una solicitud RESTful GET. La solicitud siempre debe devolver el mismo resultado cuando se llama varias veces.
no es cierto para las solicitudes GET: los recursos pueden cambiar. Que las solicitudes GET sean idempotentes solo significa que "... los efectos secundarios de N> 0 solicitudes idénticas son los mismos que para una sola solicitud" . [especulación]
Tal vez no sea la respuesta más elegante, pero saldrá a la vista con proxies de caché: simplemente no envíe la misma consulta dos veces. Agregue una marca de tiempo a la consulta ( &time=1318355458 ). De esta forma, cada solicitud es única (también puede agregar milisegundos a la hora si está solicitando> 1 hz).
En cuanto a seguir la doctrina de "La solicitud siempre debe devolver el mismo resultado cuando se llama varias veces", parece lógicamente contradictorio con el objetivo de devolver resultados parciales en diferentes momentos para la misma consulta.
No es un problema si la primera solicitud GET arroja resultados parciales, y la segunda solicitud GET devuelve los resultados completos. Esto se debe a que la primera solicitud GET no causa el cambio de la segunda solicitud: esa solicitud habría devuelto los resultados completos, incluso si el primer GET no se hubiera emitido. "idempotente" no significa resultados idénticos. Significa que el primer GET no afecta el segundo GET.
Sería un problema si la primera solicitud GET arrojara resultados parciales, y la segunda GET devolverá los resultados restantes (primero GET devuelve A, B, C; el segundo GET devuelve D, E, F). Aquí, el primer GET cambia el segundo resultado, por lo que no es RESTful.