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

Question

我很早就在一个REST实现中，最近了解到我们可以将我们的JAX-RS注释放在我们的Java服务接口上，而不是类实现上。

对我来说，看起来这可能会导致一个干净的类文件，但也可能导致开发商不得不文件之间不断地蒙混过关。

每种方法的优缺点是什么？

Answer 1

你应该把它放在一个界面中。相反，我的做法要求我将其放入界面，因为我的客户端和服务器端共享相同的jax-rs定义。

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

原因REST是允许Web服务URL API是由任何编程框架维修和“clientable”。

使用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定义运行声明以将Web服务API发布到非Java程序员。

我对这个问题的一些正在进行的散漫...... http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html。

Answer 2

我想我必须在这里恭敬地部分不同意Blessed Geek。所提到的是一个非常具体的用例，它要求在界面上使用注释。

以我自己的经验，我遇到过这样的情况，即无论是通过设计还是通过bug的框架都没有正确响应将注释放置在界面上。例如，当您将注释放置在界面上时，Apache CXF无法正确处理@PUT请求和@ PathParams，这些请求在路径中定义。不要问我为什么。CXF并不孤单; Spring Security在将注释放在接口上时遇到类似的限制。所以这是上面提到的一个对立点。

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

作为一个哲学论证，一些人认为在界面上放置注释是另一种形式的合约编程 - 你说的实现将遵守某些规则。

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

实际上，线条模糊。在定义一个宁静的端点的情况下，您可能更喜欢在界面上放置正确的注释。我认为这在大多数情况下是有意义的;您可能不会有多个实现，其中相同的方法签名会响应不同的HTTP动词。但是，您可以想出不同的实现喜欢消费和生成不同媒体类型的情况。

所以，这里的重大想法是“它取决于”。但希望这对于那些可能会偶然发现这个问题的人来说是一些思考的食物。

Answer 3

当使用JAX-RS和JAX-B时，我有类似的问题。我希望在接口上使用JAX-B注释而不是类。这不符合我的预期，原因是由于解组人员。为了解决我的问题，我最终使用了类。 Here是为什么和我发现的描述。