我很早就在REST实现中，并且最近了解到我们可以将JAX-RS注释放在我们的Java服务接口而不是类实现上。
对我来说，似乎这可能会导致一个干净的类文件，但也可能导致开发人员不得不经常混淆文件。
每种方法的优点和缺点是什么？
答案 0 :(得分：9)
你应该把它放在一个界面中。相反，我的实践要求我把它放到一个接口中，因为我的客户端和服务器端共享相同的jax-rs定义。
我倾向于将jax-rs用于REST-RPC。
REST的原因是允许Web服务URL API可以通过任何编程框架进行维护和“可客户化”。
使用jax-rs限制我们在服务器端使用java。
对REST-RPC使用jax-rs限制我们在服务器端和客户端都使用java。
什么是REST-RPC？
在一种不太复杂的解释态度中，RPC是一种在客户端上调用函数/方法的方法，当通过线路发送时，服务器提供服务，使得服务器端存在相同的函数/方法。
RestEasy允许您在客户端使用jax-rs定义来调用服务器端服务的相同功能。
RestyGWT，通过对接口进行一些修改来指定回调方法，可以（在某种程度上）在客户端和服务器端使用jax-rs定义。您只需编写脚本即可将返回类型移动到回调方法的type参数。
你可能会质疑为什么限制自己在双方执行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
答案 1 :(得分：7)
我认为我必须尊重Blessed Geek。提到的是一个非常具体的用例，需要在接口上使用注释。
根据我自己的经验，我遇到过这样的情况，即设计或bug的框架对接口上的注释没有正确响应。例如，当您在界面上放置注释时，Apache CXF无法正确处理路径中定义的@PathParams的@PUT请求。不要问我为什么。 CXF并不孤单; Spring Security在接口上放置注释时遇到类似的限制。所以这与上面提到的相反。
如果您可以自由选择放置注释的位置，我会敦促您从意图，设计和易于开发的角度考虑有意义的内容。
作为一个哲学论点，有些人说在接口上放置注释是另一种形式的合同编程 - 你说实现将遵守某些规则。
该硬币的另一面（取决于您对接口的定义）是接口不应关心其实现者在实现方法合同中定义的目标时采取的步骤。例如，为什么在可能有两个实现时在接口上放置@Transactional注释，其中一个实现不知道“事务”可能是什么？
在实践中，线条模糊。在定义restful端点的情况下，您可能更喜欢在接口上放置正确的注释。我认为在大多数情况下这是有道理的;您可能不会有多个实现，其中相同的方法签名响应不同的HTTP谓词。但是，您可能会遇到这样的情况：不同的实现更喜欢使用和生成不同的媒体类型。
所以，这里的重要思想是“它取决于”。但希望这对于那些可能偶然发现这个问题的人来说是一种值得思考的东西。
答案 2 :(得分：2)
在将JAX-RS与JAX-B一起使用时，我遇到了类似的问题。我希望在接口而不是类上使用JAX-B注释。这不像我预期的那样有效，原因是由于unmarshaller。为了解决我的问题，我最终使用了课程。 Here描述了我找到的原因和内容。