¿Cuál es la mejor manera de crear consultas complejas RESTful?

Question

¿Cuál es la mejor manera de recuperar consultas complejas de un servicio REST?

Supongamos que quiero obtener X colecciones, aplicar filtros y ecuaciones a cada una, combinar las colecciones con alguna otra operación y devolver un resultado, todo en una sola solicitud.

Es demasiado complejo (y grande) para poner todo en la cadena de consulta, ya que podría combinar más de 300 colecciones (más los operadores y filtros para cada uno).

Pensé en usar POST para enviar un objeto XML que describe la consulta a algo como:

http://mydomain/collections/complexQuery 

sería devolver un identificador único y entonces podría utilizar GET para recuperar el resultado complexQuery:

http://mydomain/collections/complexQuery/{queryId} 

Jason S:

Esa es la idea. El POST tomará una representación XML de la consulta, con los parámetros "donde" ya (pueden ser demasiados). La consulta se ejecutará solo cuando llegue el GET. Podría dejar el objeto de consulta disponible solo por un tiempo y eliminarlo más tarde.

¿Es esta una buena solución? ¿Todavía estoy RESTful haciendo esto?

Answer 1

Me resulta RESTful si usa una ID única. Si el conjunto de resultados de la consulta es grande, es posible que desee incluir una forma de solicitar las filas del conjunto de resultados M - N donde M, N son parámetros.

Supongo que una ventaja de su enfoque único de identificación (con el estado de definición de consulta almacenado en el servidor) es que podría usar el resultado de la consulta como parámetro de otra consulta. Tal vez incluso separar la publicación de la definición de una consulta de la ejecución de la consulta.

Answer 2

Este es el enfoque RESTful estándar. POST al recurso y espera 201 Created (sin cuerpo de entidad) con el URI a los resultados creados en el encabezado Location. También puede devolver los resultados con una respuesta 200 OK y, opcionalmente, un URI que indique los resultados para futura (de) referencia en la respuesta junto con una copia de los resultados.

Answer 3

Está bien. Pero introduce algunos problemas:

1. Tiene que conservar los datos de la consulta en el servidor, ¿cuándo limpia las consultas antiguas?

2. Si limpia consultas antiguas, significa que no puede proporcionar enlaces a consultas guardadas porque es posible que ya se hayan limpiado.

3. Incluso simple consulta requiere dos viajes ida y vuelta (POST & a continuación, obtener)

4. Su cliente tiene que estar familiarizado con el esquema XML que espera, en lugar de la conocida: param1=val1&param2=val2

Answer 4

lo siento, mi ignorancia ...

pero ¿por qué no solo devolver los datos con la publicación ???

Entiendo por qué es incorrecto actualizar los datos con un get, pero no veo por qué debería ser obligatorio actualizar los datos con cada publicación.

También entiendo que la idea es que cada método de obtención podría ser almacenado en caché (porque no modifican datos), pero en este caso solo podrían almacenarse en caché si la consulta guardada temporalmente sigue activa ... lo cual agrega otra capa de complejidad ...

También pensé que uno de los principios del descanso es definir interfaces sin estado (como el protocolo http), y en este caso el servidor está manteniendo un estado para resolver la consulta.

Acabo de empezar a leer sobre el descanso y hay varias cosas que aún no entiendo ...