问题描述
比方说，我有一个RESTful，超文本驱动的服务，该服务为冰淇淋商店建模.为了更好地管理我的商店，我希望能够显示一份每日报告，列出出售的每种冰淇淋的数量和美元价值.
Let's say I have a RESTful, hypertext-driven service that models an ice cream store. To help manage my store better, I want to be able to display a daily report listing quantity and dollar value of each kind of ice cream sold.
该报告功能似乎可以作为称为DailyReport的资源公开. DailyReport可以快速生成，并且在服务器上实际存储报表似乎没有任何好处.我只需要几天的DailyReport，而其他几天我不在乎获取DailyReport.此外，将DailyReports存储在服务器上会使客户端实现复杂化，需要记住删除不再需要的报告.
It seems like this reporting capability could be exposed as a resource called DailyReport. A DailyReport can be generated quickly, and there doesn't seem to be any advantage to actually storing reports on the server. I only want a DailyReport for some days, other days I don't care about getting a DailyReport. Furthermore, storing DailyReports on the server would complicate client implementations, which would need remember to delete reports they no longer need.
DailyReport是暂时的；其表示只能检索一次.实现此目的的一种方法是提供一个链接"/daily-reports"，一个POST将返回一个包含DailyReport表示形式的响应，该响应列出了当天的销售信息.
A DailyReport is transient; its representation can be retrieved only once. One way to implement this would be to offer a link "/daily-reports", a POST to which will return a response containing a DailyReport representation listing the information for that day's sales.
也可以说我确实确实想发出POST请求. DailyReport具有许多用于创建视图的选项，例如，按美元值按字母顺序对冰淇淋类型进行排序-或按小时细分-或可选地包括当天的温度-或过滤掉某些冰淇淋类型(作为列表).而不是使用查询参数与GET，我宁愿POST用适当的选项(使用良好定义的自定义的媒体类型来记录每个选项)一个DailyReport表示.我返回的表示形式将显示我的选项以及报告本身.
这是解决问题的正确方法，还是应该使用其他方法?如果正确，那么在实施DailyReport资源时，哪些特殊的注意事项可能很重要? (例如，在POST请求后返回时，可能不适合设置Location标头).
Is this the correct way to think about the problem, or should some other approach be used instead? If correct, what special considerations might be important when implementing the DailyReport resource? (For example, it probably wouldn't be appropriate to set the Location header when returning after a POST request).
推荐答案
如果您想提供过去几天的每日报告，可以将其实现为/daily_reports/2009/08/20的GET.我同意约翰·米利金(John Millikin)的观点，此处不需要POST-无需将这样的东西作为用户可创建的资源.
If you want to make daily reports for past days available, you could implement it as a GET to /daily_reports/2009/08/20. I agree with John Millikin that a POST is unnecessary here - there's no need for something like this to be a user-creatable resource.
将每天的报告作为其自己的URI可用的优点是可缓存性.
The advantage of making the report for each day available as its own URI is cacheability.
编辑:一个好的解决方案可能是合并两个答案，使daily_report/表示当日数据的不缓存，而daily_reports/yyyy/mm/dd表示当日数据的可缓存.
A good solution might be to merge the two answers, making daily_report/ a no-cache representation of the current day's data and daily_reports/yyyy/mm/dd a cacheable representation of a full day's data.
这篇关于瞬时REST表示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！