阅读一些RESTful API设计最佳实践。我来自ASP.Net Web窗体背景，我一直在调用WebMethods后面的代码将数据返回给我的客户端javascript。对我来说，似乎逻辑上将这些WebMethods移到API中，这样我们就可以开始集中化和标准化我们回调终端系统的方式。
我理解REST的目的是将资源上的操作分类为GET，POST，PUT和DELETE。同样可以使用名词代替动词来获取这些资源。
1） 所以我有两种方法可以返回数据来生成报告。由于客户端绑定和每个报告的其他特定属性，我创建了各自的Classes BreakdownIncidents和BreakdownMinutes。
[WebMethod] Top10MinutesBreakdowns
|Machine|Department|Total Minutes|etc.|
[WebMethod] Top10IncidentsBreakdowns
|Machine|Department|Total Incidents|etc.|
这些方法是否应该有条理：
GET /Breakdowns?report=minutes&type=top10
GET /Breakdowns?report=incidents&type=top10
然后在我的Breakdown控制器中检查参数并调用相应的现有业务层函数来返回数据？
2）报告返回两个不同的属性（简单起见：分钟数和事件数）。我真的应该将这两种方法分组到同一个控制器中吗？
这是我感到困惑的地方，因为报告使用了不同的属性，但基础对象是细分。也许这个问题更适合重新设计我的业务对象本身。我发现我们现有的业务层有很多用于绑定客户端视图的类。我确信在尝试构建此API时，我会遇到更多这些场景。
答案 0 :(得分：0)
让两个调用返回不同的资源都没问题。只需将report参数视为一种属性过滤器即可。如果未传递report参数，只需将两个属性作为细分资源的一部分返回。
您还可以包含一个fieldset参数，使返回的属性更加明确，例如：/api/breakdown?fieldset=machine,department,minutes。
如果您有许多报告，每个资源都有各种各样的属性，您可以考虑GraphQL之类的内容，它允许您在单个查询中显式指定要返回的多个资源的属性。
答案 1 :(得分：0)
我理解REST的目的是将资源上的操作分类为GET，POST，PUT和DELETE。同样可以使用名词代替动词来获取这些资源。
不是真的 - REST的目标是明确支持Web规模应用程序所需的约束。见Fielding, 2000
这是我感到困惑的地方，因为报告使用了不同的属性，但基础对象是细分。
不要将API与底层实现/表示混淆。 Top10MinutesBreakdowns和Top10IncidentsBreakdowns 信息资源碰巧使用对同一底层对象的引用这一事实是您当前实现的意外。
换句话说，您的控制器是适配器，支持幻觉只是一个了解HTTP请求消息的文档存储。
选择在同一个控制器或不同控制器中支持这两个报告，实际上取决于这些报告相对于彼此的变化频率，自定义请求路由到相应控制器的成本等等。
任何可以正确路由的URI拼写都可以，但我个人倾向于将这些报告标识为自己的。
GET /Top10MinutesBreakdowns
GET /Top10IncidentsBreakdowns
然后配置路由以将这些请求传递到适当的控制器。