在界面中使用@RequestMapping 是不是一个坏主意？答案

【问题标题】：Is it a bad idea to use @RequestMapping in interface?在界面中使用@RequestMapping 是不是一个坏主意？
【发布时间】：2019-05-17 07:01:01
【问题描述】：

我查看了这个SO Post，它讨论了在界面中使用RequestMapping。虽然这篇文章包含了实现这一目标的方法，但并未提及这样做的利弊。

架构明智，使用控制器作为接口是一个坏主意吗？我们将在控制器的多态性方面获得什么好处？

【问题讨论】：

真的没有意义，因为您只能有一个具有该映射的活动控制器。所以你可以直接在实现类中定义它。
@Lino 这取决于
@jbx 我同意，确实如此。但如果没有来自 OP 的更多信息，目前还不清楚这是一个好主意还是一个坏主意
@Lino 没错。

标签： java spring rest spring-mvc polymorphism

【解决方案1】：

在界面上放@RequestMapping没有错。但是，请确保您有正确的理由这样做。多态性可能不是一个好的理由，您不会在运行时换入不同的具体实现或类似的东西。

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

如果您选择这样做，请确保使用最新版本的 Spring 框架，因为有一些错误是最近才修复的，并非所有注释都被继承。 https://github.com/spring-projects/spring-framework/issues/15682

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

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

【讨论】：

【解决方案2】：

虽然反对这一点的一些论据是

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

我最近面临同样的决定，将 jax-rs 注释放在接口或实现上。所以，由于一切总是“依赖”于某些上下文，我想给你一个论据，将RequestMapping（或者例如@Path，如果不使用spring，等等）放在接口上：

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

【讨论】：

另一个很好的例子是使用来自 Yaml 的 Swagger / OpenAPI codegen 生成合约优先服务接口。