与Jersey和JSR相关的JAX-RS

我试图了解Java中的一些概念：

JSR：描述规范，但没有实际实现。例如， http：//jsr311.java.net/是“用于RESTful Web服务的Java™API”的“主页”。它是JSR-311所有实现的通用参考。
可以从http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api下载JSR-311的接口（？），但是，除非您自己实现JSR-311，否则它们没有特别的价值？
JSR通常/总是有一个参考实现。要找到它，你必须google“JSR XXX参考实现”或查看规范主页（例如http://jsr311.java.net/ ）
对于JSR-311，这个参考实现是Jersey 。使用maven，您可以从http://mvnrepository.com/artifact/com.sun.jersey/jersey-server/1.9获取jersey服务器。由于Jersey根据http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api中的接口提供了一个实现，因此您只需要在项目中添加Jersey作为依赖项，而不是jsr311-api本身。（这适用于所有JSR技术？）
将http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api和http://mvnrepository.com/artifact/com.sun.jersey/jersey-server/1.9作为项目中的依赖项放在一起导致类路径问题？

我是完全不喜欢的吗？

是的，这不是什么新鲜事。想想JDBC，java提供了接口（ Connection ， Statement ， ResultSet等），但是由数据库供应商提供实现。
如果您正在使用像Jersey或Apache CXF这样的JSR-311实现，那么您将使用javax.ws.rs注释来注释您的类，例如@GET @Path ， @GET ， @GET @Produces等。这就是您需要明确的原因将JSR-311作为maven依赖。
是的，通常。看看wiki上的JSR列表。
您需要JSR和实现。注释在JSR中，实现提供了支持类，例如com.sun.jersey.spi.container.servlet.ServletContainer 。
不，有必要兼顾两者（见第4点）; 你不会得到类路径冲突。

–
可以从各种来源下载文件。要获得JSR-311规范的最正式版本，请转到其JCP下载页面。您很可能无法从JCP页面获取JAR文件（包含所有接口和内容），但这仍然是官方来源。（公共草稿总是有很好的PDF格式！）
–
你没错，因为Jersey包含JSR-311定义的API，但我会在jsr311-api JAR文件中添加编译依赖项，并将Jersey添加为运行时依赖项。这在API和实现之间创建了一个很好的分离，您可以随时更换JSR-311实现[ 原文如此 ]。如果你打算一直使用泽西岛只包括泽西岛。 POM中的依赖性减少一个。
如果Jersey包含与jsr311-api JAR包含的API相同的API，则不会。如果它包装了不同的东西，那么，那将是非常糟糕的！如果在其类路径上有一个损坏的 JSR-311 API，Maven可能会在编译时吠叫（我已经在方法中看到了很多java.lang.ClassFormatError：Absent Code属性……错误，所以它不会去没有注意到，这是肯定的）。

除此之外，你是对的。