Переходные REST-представления

Question

Допустим, у меня есть RESTful, гипертекстовый сервис, который моделирует магазин мороженого. Чтобы лучше управлять своим магазином, я хочу иметь возможность отображать ежедневный отчет с указанием количества и стоимости в долларах каждого проданного мороженого.

Кажется, что эта возможность создания отчетов может быть представлена ​​как ресурс под названием DailyReport. DailyReport может быть сгенерирован быстро, и нет никакого преимущества в том, чтобы фактически хранить отчеты на сервере. Я хочу, чтобы DailyReport был только на несколько дней, в другие дни меня не интересует получение DailyReport. Кроме того, хранение DailyReports на сервере может усложнить реализацию клиента, что может привести к удалению отчетов, которые им больше не нужны.

Ежедневный отчет является переходным; его представление может быть получено только один раз. Одним из способов реализации этого было бы предложить ссылку «/ daily-reports», POST, на которую будет возвращаться ответ, содержащий представление DailyReport со списком информации о продажах за этот день.

Редактировать: Давайте также скажем, что я действительно хочу сделать запрос POST. В DailyReport есть много различных вариантов создания представления, например, сортировка типов мороженого по алфавиту, по долларовой стоимости - или с учетом почасовой разбивки - или, при желании, с учетом температуры на этот день - или отфильтровывание определенных типов мороженого (в виде списка). Вместо того, чтобы использовать параметры запроса с GET, я бы предпочел POST представление DailyReport с соответствующими опциями (используя четко определенный пользовательский тип мультимедиа для документирования каждой опции). Представление, которое я получаю, будет отображать мои параметры вместе с самим отчетом.

Это правильный способ думать о проблеме, или вместо этого следует использовать какой-то другой подход? Если все правильно, какие особые соображения могут быть важны при реализации ресурса DailyReport? (Например, вероятно, было бы неправильно устанавливать заголовок Location при возврате после запроса POST).

Answer 1

Если вы хотите сделать ежедневные отчеты за прошлые дни доступными, вы можете реализовать их как GET для /daily_reports/2009/08/20. Я согласен с Джоном Милликином в том, что POST здесь не нужен - нет необходимости создавать что-то подобное для пользователя.

Преимуществом предоставления отчета за каждый день в виде собственного URI является кешируемость.

РЕДАКТИРОВАТЬ: Хорошим решением может быть объединение двух ответов, делая daily_report/ представление данных без кэша текущего дня и daily_reports/yyyy/mm/dd кэшируемое представление данных полного дня.

Answer 2

Иногда желательно вести учет запросов на отчеты, в таких случаях POST-запрос к ресурсу сбора не является необоснованным. Это также полезно для долгосрочных отчетов, где вы хотите обрабатывать выполнение асинхронно. Как долго сервер удерживает эти запросы отчетов, зависит от вас.

Я бы сделал что-то вроде

POST /DailyReportRequests

, который будет возвращать представление запроса, включая параметры, а по завершении отчета - ссылку на результаты отчета.

Другой альтернативой, которая хороша, когда у вас есть набор предварительно настроенных отчетов, является создание ресурса DailyReports, который содержит список предварительно настроенных ссылок на отчеты. Спецификация OpenSearchDescription позволяет вам сделать что-то похожее, используя тег Query.

Answer 3

Нет необходимости использовать POST для этого, так как запрос отчета не меняет состояние сервера. Я бы использовал такой ресурс:

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>

---

Ответ на ваше редактирование: если вы отправляете описание отчета по URL-адресу и в результате извлекаете временный набор данных, это вовсе не REST. Это RPC, в том же духе, что и SOAP. RPC по сути не плохая вещь, но, пожалуйста, не называйте это RESTful.

Answer 4

Я думаю Подход Грега правильный. Чтобы пояснить это, я не думаю, что вы должны предоставлять /daily-report ресурс, который меняется ежедневно, потому что запуск отчета во вторник в 11:59 даст другие результаты, чем запуск в среду в 00:01, что может быть А) сбивает с толку клиентов, ожидающих, что ресурс будет таким же, и B) не позволяет клиентам получать данные за предыдущий день после того, как день прошел. Вы должны предоставить уникальный идентификатор ресурса для каждого доступного ежедневного отчета, чтобы клиенты могли в любое время получить доступ к необходимой им информации.