Question

在我们的Jersey 1.9代码中，我们有一个注释处理器，它在构建时运行并生成REST API的文档。它通过查找@Paths然后查看消耗的表单bean和JResponses来实现此目的。由于JResponse可以采用类似

的通用

public JResponse<MyRepresentation> findMyEntity(Long id)

API文档生成器将读取类似的方法，查看泛型返回类型，并能够反映生成基于MyRepresentation的响应定义。在Jersey 2.x中，我看不到像JResponse这样的东西。

Jersey 2.x资源方法是否有类似的通用返回/响应类型？

Answer 1

这甚至值得吗？

在没有真正得到满意的答案后，我开始假设没有其他人真正使用此功能，他们不会因失去它而感到不安，或者根本没有令人满意的答案。 / p>

我真的很喜欢简单的，编译器强制的，自我记录的API。它总是同步的，因为如果返回的类型不匹配，编译器会抱怨，不需要代码内注释或外部文档结构。为此，我认为重要的是我们可以忍受少量的孤立＆＃34; hackiness＆＃34;为了实现API zen。

尝试解决方案

我的第一个想法是通过public class JResponse<E> extends Response创建一个新的JResponse，但它提供的默认功能几乎为零。所以，在泽西土地深处，我考虑public class JResponse<E> extends OutboundJaxrsResponse。问题仍然在于构建内置的ResponseBuilder来生成OutboundJaxrsResponse，而不是我的generecized JResponse。似乎应该有一种方法可以注入你自己的ResponseBuilder，但是当添加泛型时我无法真正弄明白如何做到（如果有人想出来的话，那就是它听起来它可能是比我提出的更好的解决方案。）

我最终得出的最终解决方案是一个扩展OutboundJaxrsResponse的抽象类和三个特定于响应代码的类，Ok<E>，Created<E>和{{1} }被调用为

NoContent

事实证明，我们在实践中使用了非常少量的整体Response API（成功代码只有200,201和204，没有300＆＃39;以及通过抛出异常的所有400+）这意味着重做整个建造者模式是不必要的。最后，它出现了

好的：静态空，静态实体（E实体）创建：静态uri，实例实体（E实体） NoContent：静态空

创建的示例为// Some resource method @Path("data/find") public static Ok<MyDataRep> findData(@Valid MyDataRequestBean form) { // find entity etc MyDataRep somePojo = ...; return Ok.entity(somePojo); }

<强>缺点

不讨论存在的缺点是不公平的，其中有一些主要缺点。

首先，由于Response仍然是祖先（根据Jersey的要求），所有Response静态方法都可见并显示在IDE自动完成中。由于return Created.uri(someBuiltUri).entity(somePojo);与Ok.ok()不匹配，因此在您熟悉我在这里创建的方言之前，很难意识到出了什么问题。这可以通过工厂解决，但会增加复杂性。

其次，在泽西岛内部有一个地方，它会确保在您返回任何通用内容时使用正确的类型。有一张支票要说＆＃34;如果这是一个响应的实例，请不要进行检查＆＃34;但我相信它有问题。结果是泽西岛错误地破坏了你的类型，然后爆炸了。为了解决这个问题，我必须做以下事情：

Ok<E>

这可以防止错误地重写类型信息。

第三，public static class CustomOutboundMessageContext extends OutboundMessageContext { @Override public void setEntityType(Type type) {} }中的评论非常具体地要求我们不要这样做：

Response

第四，我不认为忽视泽西岛内部依赖的脆弱性是公平的，尽管它不会比依赖于/** * An application class should not extend this class directly. {@code Response} class is * reserved for an extension by a JAX-RS implementation providers. An application should use one * of the static methods to create a {@code Response} instance using a ResponseBuilder.更脆弱。第一名。幸运的是，如果必须的话，我们总是可以回到JResponse;该选项仍然可用。

<强>结论

这些更改在我们的特定项目中非常容易使用，并且允许我们生成API定义而无需维护注释。总的来说，我仍觉得值得为我们付出努力，但我不能推荐这是一个理想的解决方案。

Jersey 2.5：JResponse的替换？

1 个答案: