Representaciones REST transitorias

Question

Digamos que tengo un servicio RESTful impulsado por hipertexto que modela una heladería. Para ayudar a administrar mejor mi tienda, quiero poder mostrar un informe diario que enumere la cantidad y el valor en dólares de cada tipo de helado vendido.

Parece que esta capacidad de informe podría exponerse como un recurso llamado DailyReport. Un DailyReport se puede generar rápidamente, y no parece haber ninguna ventaja para almacenar realmente los informes en el servidor. Solo quiero un DailyReport por algunos días, otros días no me importa obtener un DailyReport. Además, el almacenamiento de DailyReports en el servidor complicaría las implementaciones de los clientes, que deberían recordar eliminar los informes que ya no necesitan.

Un DailyReport es transitorio; su representación puede ser recuperada solo una vez. Una forma de implementar esto sería ofrecer un enlace "/ daily-reports", un POST al que se devolverá una respuesta que contiene una representación de DailyReport que enumera la información para las ventas de ese día.

Editar: Digamos que realmente quiero hacer una solicitud POST. Un InformeDiarial tiene muchas opciones diferentes para crear una vista, como ordenar los tipos de helado alfabéticamente, por valor en dólares (o incluir un desglose por hora) u opcionalmente incluir la temperatura de ese día o filtrar ciertos tipos de helado (como una lista). En lugar de utilizar parámetros de consulta con un GET, prefiero PUBLICAR una representación DailyReport con las opciones adecuadas (utilizando un tipo de medio personalizado bien definido para documentar cada opción). La representación que obtengo mostrará mis opciones junto con el informe en sí.

¿Es esta la forma correcta de pensar sobre el problema, o debería usarse algún otro enfoque? Si es correcto, ¿qué consideraciones especiales pueden ser importantes al implementar el recurso DailyReport? (Por ejemplo, probablemente no sea apropiado configurar el encabezado de ubicación cuando se devuelve después de una solicitud POST).

Answer 1

Si desea hacer informes diarios de los días pasados ​​disponibles, puede implementarlo como GET a /daily_reports/2009/08/20. Estoy de acuerdo con John Millikin en que un POST es innecesario aquí; no es necesario que algo como esto sea un recurso creado por el usuario.

La ventaja de hacer que el informe de cada día disponible como su propio URI sea almacenable en caché.

EDIT: Una buena solución podría ser la de fusionar las dos respuestas, haciendo daily_report/ una representación no-cache de los datos del día actual y daily_reports/yyyy/mm/dd una representación almacenable en caché de los datos de un día completo.

Answer 2

No es necesario utilizar un POST para esto, ya que solicitar el informe no cambia el estado del servidor. Me gustaría utilizar un recurso como este:

GET /daily-report/ 

200 OK 
Pragma: no-cache 
<daily-report for="2009-04-20" generated-at="2009-4-20T12:13:14Z"> 
    <!-- contents of the report here --> 
</daily-report> 

---

respuesta a tu edición: si envías una descripción del informe a una dirección URL, y recuperar un conjunto de datos temporales establecidos como resultado, eso no descansar en todas. Es RPC, en la misma línea que SOAP. RPC no es intrínsecamente malo, pero, por favor, no lo llame RESTful.

Answer 3

Creo que Greg's approach es el correcto. Para exponerlo, no creo que deba proporcionar un recurso /daily-report que cambie a diario, ya que ejecutar el informe el martes a las 11:59 arrojaría resultados diferentes que ejecutarlo el miércoles a las 00:01, que puede ser A) confuso para los clientes que esperan que el recurso sea el mismo, y B) no permite a los clientes recuperar los datos de un día anterior después de que el día haya pasado.Debe proporcionar un identificador único de recursos para cada informe diario que esté disponible, de esa manera los clientes pueden acceder a la información que necesitan en cualquier momento.

Answer 4

A veces es conveniente mantener un registro de las solicitudes de informes, en esos casos no es irrazonable enviar a un recurso de recopilación. También es útil para informes de larga ejecución en los que desee manejar la ejecución de forma asincrónica. El tiempo que el servidor tenga esas solicitudes de informes depende de usted.

Me gustaría hacer algo como

POST /DailyReportRequests 

que devolver una representación de la solicitud, incluyendo las opciones, y cuando se completa el informe, un enlace a los resultados del informe.

Otra alternativa que es buena cuando tienes un conjunto de informes pre-enlatados es crear un recurso DailyReports que contenga una lista de enlaces de informes preconfigurados. La especificación OpenSearchDescription le permite hacer algo similar a esto usando la etiqueta Consulta.