REST风格的API命名资源和控制器设计

Question

只需阅读一些RESTful API设计最佳实践即可。我来自ASP.Net Web窗体背景，我一直在调用WebMethods后面的代码来将数据返回给我的客户端JavaScript。对我来说，将这些WebMethod移出到一个API似乎逻辑上，所以我们可以开始集中和标准化我们如何回调终端系统。

我理解REST的目的是对资源为GET，POST，PUT和DELETE分类的操作。这些资源也可以使用名词而不是动词。

1） 所以我有两个方法，返回的数据生成报表。由于客户端绑定和每个报告的其他特定属性，我创建了各自的类别细分突发事件和细分分钟。

[的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 

然后在我的故障控制器中检查参数并调用相应的现有业务层功能来返回数据？

2）报告返回两个不同的特性（简单起见：分钟和事件＃）的＃。我真的应该将这两种方法分组到同一个控制器吗？

这是我很困惑，因为报表使用不同的属性，但根本目的是击穿。也许这个问题更适合重新设计我的业务对象本身。我发现我们现有的业务层有很多为绑定客户端视图而创建的类。我确信在尝试构建此API时会遇到更多这些场景。

Answer 1

这是没有问题的有两个调用返回一个不同的资源。只要将报告参数视为属性过滤器的一种。如果您未通过报告参数，则只需返回两个属性作为细分资源的一部分即可。

你还可以包括一个字段参数，使返回的属性更加明确，如：/api/breakdown?fieldset=machine,department,minutes。

如果您有许多具有各种资源属性的报表，您可能会考虑类似于GraphQL，它允许您显式指定多个资源的属性以在单个查询中返回。

Answer 2

我知道REST的目标是将资源上的操作分类为GET，POST，PUT和DELETE。这些资源也可以使用名词而不是动词。

不是真的 - REST的目标是明确支持网络规模应用程序所需的约束条件。见Fielding, 2000

这是我很困惑，因为报告使用不同的属性，但基础对象是一个分解。

不要将您的API与您的底层实现/表示混淆。 Top10MinutesBreakdowns和Top10IncidentsBreakdowns 信息资源碰巧使用对同一个基础对象的引用，这是您当前实现的意外。

换句话说，您的控制器是适配器，支持错觉只是一个理解HTTP请求消息的文档存储。

选择在相同的控制器或不同的控制器中支持这两个报告确实取决于这些报告相对于彼此的变化频率，自定义请求路由到相应控制器的成本等等。

任何您可以正确路由的URI拼写都可以，但我个人倾向于给这些报告标识符自己。

GET /Top10MinutesBreakdowns 
GET /Top10IncidentsBreakdowns 

然后配置您的路由以将这些请求传递到相应的控制器。