7

假设我有一个 RESTful、超文本驱动的服务，它为冰淇淋店建模。为了帮助更好地管理我的商店，我希望能够显示每日报告中列出的每种销售的冰淇淋的数量和美元价值。

似乎这种报告功能可以作为一种名为 DailyReport 的资源公开。DailyReport 可以快速生成，并且在服务器上实际存储报告似乎没有任何优势。我只想要一个 DailyReport 几天，其他日子我不关心获得 DailyReport。此外，将 DailyReports 存储在服务器上会使客户端实现复杂化，需要记住删除不再需要的报告。

DailyReport 是短暂的；它的表示只能检索一次。实现这一点的一种方法是提供一个链接“/daily-reports”，一个 POST 将返回一个响应，其中包含一个 DailyReport 表示，列出了当天的销售信息。

编辑：假设我真的想做一个 POST 请求。DailyReport 有许多不同的选项可用于创建视图，例如按字母顺序、按美元价值对冰淇淋类型进行排序 - 或包括每小时细分 - 或可选地包括当天的温度 - 或过滤掉某些冰淇淋类型（作为列表）。不是使用Get的查询参数，而不是使用适当的选项发布DailyReport表示（使用明确定义的自定义介质类型来记录每个选项）。我返回的表示将显示我的选项以及报告本身。

这是思考问题的正确方法，还是应该使用其他方法？如果正确，在实现 DailyReport 资源时，哪些特殊注意事项可能很重要？（例如，在 POST 请求后返回时设置 Location 标头可能不合适）。

4

4 回答 4

4

如果您想提供过去几天的每日报告，您可以将其实现为 GET 到/daily_reports/2009/08/20. 我同意 John Millikin 的观点，这里不需要 POST - 不需要像这样的东西成为用户可创建的资源。

将每天的报告作为其自己的 URI 提供的优点是可缓存性。

编辑：一个好的解决方案可能是合并这两个答案，使daily_report/当天数据的无缓存表示和全天数据daily_reports/yyyy/mm/dd的可缓存表示。

于 2009-08-20T22:10:37.860 回答
2

不需要为此使用 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。

于 2009-08-20T22:08:44.400 回答
2

有时需要记录对报告的请求，在这些情况下，将 POST 发送到集合资源并非不合理。它对于您希望异步处理执行的长时间运行的报告也很有用。服务器保留这些报告请求的时间取决于您。

我会做类似的事情

POST /DailyReportRequests

这将返回请求的表示，包括选项，并且当报告完成时，报告结果的链接。

当您拥有一组预置报告时，另一个很好的替代方法是创建一个 DailyReports 资源，其中包含一个预配置报告链接的列表。OpenSearchDescription规范允许您使用 Query 标记执行与此类似的操作。

于 2009-08-20T23:31:37.587 回答
1

我认为格雷格的方法是正确的。为了说明这一点，我认为您不应该提供/daily-report每天都在变化的资源，因为在周二 11:59 运行报告会产生与周三在 00:01 运行报告不同的结果，这可能 A) 让客户感到困惑期望资源相同，并且 B) 不允许客户端在一天过去后检索前一天的数据。您应该为每个可用的每日报告提供唯一的资源标识符，这样客户就可以随时访问他们需要的信息。

于 2009-08-20T22:16:48.457 回答