在接口中使用@RequestMapping是一个坏主意吗？

Question

我检出了这个SO Post，其中讨论了如何在界面中使用RequestMapping。尽管该帖子包含实现此目标的方法，但并未提及这样做的利弊。

明智的架构设计，将控制器用作接口是一个坏主意吗？ 就控制器的多态性而言，我们将获得什么好处？

Answer 1

将@RequestMapping放在界面上没有任何问题。但是，请确保您有正确的理由这样做。多态可能不是一个好理由，您将不会在运行时或类似的情况下交换其他具体实现。

例如，Swagger代码生成器生成带有@RequestMapping的接口以及方法，字段和返回类型（以及@Api定义等）上的所有注释。然后，您的控制器将实现此接口。在这种情况下，这很有意义，因为它只是在强制您遵守Yaml中最初定义的Swagger / OpenAPI接口定义。有一个很好的副作用，它可以使您的控制器更加整洁。 （客户端也可以使用相同的Yaml为自己的语言框架生成自己的客户端存根。）

如果选择执行此操作，请确保使用最新版本的Spring Framework，因为有些错误仅在最近才得到修复，而并非所有注解都得到了继承。 https://github.com/spring-projects/spring-framework/issues/15682

如果您使用的是较早的Spring版本，则可能需要在控制器中重复相同的注释。

因此，这样做的真正原因是强制执行接口协定，并将接口定义（以及与该接口有关的任何信息）与实际的具体实现分开。

Answer 2

与此相反的是

• 请求映射是实现细节，或
• 由于您只有一个活动的控制器实现，因此不妨将其放在实现中，
• （很快就会为其他人提供其他答案）

我最近也面临着将jax-rs注释放在接口或实现上的相同决定。因此，由于所有内容始终都“依赖”某些上下文，因此我想给您提供一个参数，用于将RequestMapping（或@Path等，如果不使用spring的话）放在接口上：

• 如果您不使用HATEOAS或通过其他方式发现端点，则端点url，http方法等通常是固定的，并且是后端API的静态部分。因此，您最好将其放在接口上。对我来说就是这样，因为我同时控制客户端和服务器端。
• 该控制器通常只有一个活动的实现，因此这样做的原因不是多态。但是您的实现通常比纯接口具有更多的依赖关系。因此，如果仅向客户端导出/提供接口（例如在单独的jar / java项目/ ...中），则仅提供客户端真正需要的内容。在我的特定情况下，我提供了带注释的接口，以便客户端实现可以使用Rest-Client-Library并自动检测端点路径。