JAX-RS 注释：最好放在接口或类上？

您应该将其放在界面中。相反，我的实践要求我将其放入接口中，因为我的客户端和服务器端共享相同的jax-rs定义。

我倾向于使用jax-rs进行REST-RPC。

REST的原因是允许Web服务URL API可以通过任何编程框架进行服务和“可客户端化”。

jax-rs的使用限制了我们在服务器端使用java。

将 jax-rs 用于 REST-RPC 限制了我们在服务器端和客户端都使用 java。

什么是 REST-RPC？

在不太复杂的解释态度中，RPC是一种在客户端上调用函数/方法的方法，当通过网络发送时，它由服务器提供服务，因此在服务器端存在相同的函数/方法。

RestEasy 允许您在客户端使用 jax-rs 定义来调用在服务器端服务的相同函数。

RestyGWT也一样，通过对接口进行一些修改以指定回调方法，将允许您（在某种程度上）在客户端和服务器端使用jax-rs定义。您只需编写一个脚本即可将返回类型移动到回调方法的类型参数。

你可能会问，为什么限制我们自己在两边执行java？这难道不会破坏REST生活中的目的之一吗？我认为 jax-rs REST-RPC 是实现和测试 jax-rs 服务的便捷途径。如果你想实现一个 jax-rs 服务，你可能最初会在 Java 中同时做到这一点。然后，当你的服务开始工作时，你可以开始编写PHP或python客户端。

在接口文件中编写 jax-rs 将允许您发布用于客户端操作的接口。对于 REST-RPC 尤其如此。但是，您可以在 jax-rs 定义上运行 enunciate，以将 Web 服务 API 发布给非 Java 程序员。

我有一些关于这个主题的持续闲逛...http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html。

我认为我必须尊重地部分不同意Blessed Geek在这里。提到的是一个非常具体的用例，需要在界面上使用注释。

根据我自己的经验，我遇到过这样的情况，即框架无论是设计上的还是错误都无法正确响应在界面上放置注释。例如，当您在接口上放置注释时，Apache CXF 不会正确处理路径中定义了@PathParams@PUT请求。不要问我为什么。CXF并不孤单。Spring Security在接口上放置注释时也存在类似的限制。因此，这与上面提到的观点是对立的。

如果您可以自由选择放置注释的位置，我建议您从意图，设计和易于开发的角度考虑什么是有意义的。

作为一个哲学论点，有些人说在接口上放置注释是另一种形式的契约编程 - 你是说实现将遵守某些规则。

硬币的另一面（取决于你对接口的定义）是接口不应该关心它们的实现者在实现方法契约中定义的目标时采取了哪些步骤。例如，当您可能有两个实现时，为什么要在接口上放置@Transactional注释，其中一个实现不知道“事务”可能是什么？

在实践中，线条模糊不清。在定义 Restful 终结点的情况下，您可能更愿意在接口上放置适当的注释。我认为这在大多数情况下是有道理的。您可能不会有多个实现，其中相同的方法签名响应不同的HTTP谓词。但是，您可能会遇到不同的实现更喜欢使用和生成不同媒体类型的情况。

所以，这里最大的想法是“视情况而定”。但希望对于那些可能偶然发现这个问题的人来说，这是一些值得思考的食粮。