瞬态 REST 表示
假设我有一个 RESTful、超文本驱动的服务，用于模拟冰淇淋店。为了帮助更好地管理我的商店，我希望能够显示每日报告，列出所售每种冰淇淋的数量和美元价值。
看来这种报告功能可以作为名为 DailyReport 的资源公开。 DailyReport 可以快速生成，并且在服务器上实际存储报告似乎没有任何优势。我只想要某些日子的每日报告，其他日子我不关心是否获得每日报告。此外，将 DailyReports 存储在服务器上会使客户端实现变得复杂，这需要记住删除不再需要的报告。
DailyReport 是短暂的；它的表示只能被检索一次。实现此目的的一种方法是提供一个链接“/daily-reports”，该 POST 将返回包含 DailyReport 表示的响应，其中列出了当天的销售信息。
编辑：我们还可以说我确实想要执行 POST 请求。 DailyReport 有许多不同的选项用于创建视图，例如按字母顺序、按美元价值对冰淇淋类型进行排序 - 或包括每小时细分 - 或可选地包括当天的温度 - 或过滤掉某些冰淇淋类型（作为列表）。我不想将查询参数与 GET 一起使用，而是使用适当的选项来 POST DailyReport 表示（使用明确定义的自定义媒体类型来记录每个选项）。我得到的表示将与报告本身一起显示我的选项。
这是思考问题的正确方法，还是应该使用其他方法？如果正确，那么在实施 DailyReport 资源时哪些特殊注意事项可能很重要？ （例如，在 POST 请求后返回时设置 Location 标头可能不合适）。
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.
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.
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.
Edit: Let's also say that I really do want to do a POST request. A DailyReport has many different options for creating a view such as sorting ice cream types alphabetically, by dollar value - or including an hourly breakdown - or optionally including the temperature for that day - or filtering out certain ice cream types (as a list). Rather than using query parameters with a GET, I'd rather POST a DailyReport representation with the appropriate options (using a well-defined custom media type to document each option). The representation I get back would display my options along with the report itself.
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).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您想提供过去几天的每日报告，您可以将其实现为
/daily_reports/2009/08/20的 GET。我同意 John Millikin 的观点，即这里不需要 POST - 不需要像这样的东西成为用户可创建的资源。将每天的报告作为其自己的 URI 提供的优点是可缓存。
编辑：一个好的解决方案可能是合并两个答案，使
daily_report/成为当天数据的无缓存表示，而daily_reports/yyyy/mm/ dd全天数据的可缓存表示。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.The advantage of making the report for each day available as its own URI is cacheability.
EDIT: A good solution might be to merge the two answers, making
daily_report/a no-cache representation of the current day's data anddaily_reports/yyyy/mm/dda cacheable representation of a full day's data.无需为此使用 POST，因为请求报告不会更改服务器的状态。我会使用这样的资源：
响应您的编辑：如果您将报告的描述发布到 URL，并作为结果检索临时数据集，那么这根本不是 REST。它是 RPC，与 SOAP 类似。 RPC 本质上并不是一件坏事，但是请不要称其为 RESTful。
There's no need to use a POST for this, since requesting the report doesn't change the state of the server. I would use a resource like this:
Responding to your edit: if you are POSTing a description of the report to a URL, and retrieving a temporary data set as a result, that's not REST at all. It's RPC, in the same vein as SOAP. RPC is not an inherently bad thing, but please, please don't call it RESTful.
有时需要保留报告请求的记录，在这些情况下，POST 到集合资源并非不合理。对于需要异步处理执行的长时间运行的报表也很有用。服务器保留这些报告请求的时间由您决定。
我会做类似的事情
，返回请求的表示，包括选项，并在报告完成时返回报告结果的链接。
当您拥有一组预制报告时，另一个不错的选择是创建包含预配置报告链接列表的 DailyReports 资源。 OpenSearchDescription 规范允许您使用查询标记执行类似的操作。
Sometimes it is desirable to keep a record of requests for reports, in those cases it is not unreasonable to POST to a collection resource. It is also useful for long running reports where you want handle the execution asynchronously. How long the server holds onto those report requests is up to you.
I would do something like
which would return a representation of the request, including options, and when the report is completed, a link to the report results.
Another alternative which is good when you have a set of pre-canned reports is to create a DailyReports resource that contains a list of preconfigured report links. The OpenSearchDescription spec allows you to do something similar to this using the Query tag.
我认为 Greg 的方法是正确的。为了说明这一点，我认为您不应该提供每天都会更改的
/daily-report资源，因为周二 11:59 运行报告会产生与周三 00 点运行报告不同的结果:01，这可能是 A) 让期望资源相同的客户端感到困惑，B) 不允许客户端在当天过去后检索前一天的数据。您应该为每个可用的每日报告提供唯一的资源标识符，这样客户就可以随时访问他们需要的信息。I think Greg's approach is the correct one. To expound upon it, I don't think you should provide a
/daily-reportresource that changes daily, because running the report on Tuesday at 11:59 would yield different results than running it Wednesday at 00:01, which can be A) confusing for clients expecting the resource to be the same, and B) doesn't allow clients to retrieve a previous day's data after the day has passed. You should provide a unique resource identifier for each daily report that's available, that way clients can access the information they need at any time.