JAX-RS/Jersey 中什么更好 - 使用 containerResponseFilter 或 MessageBodyWriter Provider?

发布于 2024-12-20 01:10:13 字数 1428 浏览 2 评论 0原文

我正在使用 Jersey Server 开发 API。我在一个 bean 中定义了一个公共根元素,目前我使用容器响应过滤器包装来自资源(另一个 bean)的响应。效果很好。

它基本上返回这个:

<transaction>
   <status>Good</status>
   <id>1</id>
   ....
</transaction>

所以它基本上将事务元素和状态元素包装在从资源返回的 bean 周围,该 bean 使用 javax.xml 绑定注释进行注释。

我们正在考虑实现 OData 格式,它提供 Atom 样式的 XML 和 JSON。两者的格式确实不同。因此,如果请求返回的媒体类型是 application/xml,则过滤器将像现在一样工作。如果请求的媒体类型是application/atom+xml,则需要返回一个atom风格的xml文档。

<feed xlmns="http://www.w3.org/2005/Atom"
      xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
      xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">
  <title>resource name</title>
  .....
</feed>

如果请求的媒体类型是 application/JSON,则需要返回 OData 的 JSON 格式,如下所示:

"d" : {
  "results" : [
  {
    "__metadata": { 
      "uri" : "http://www.url.com/api/resource" 
    },
    "title" : "reource name",
    ....
  ]}
}

我找到了有关设置实现 MessageBodyWriter 的提供程序的在线文档和示例。我可以为每种类型指定一个提供者。因此, Produce 注释将具有适当的媒体类型,并且 isWriteable 方法也会检查适当的类型。然后 writeTo 方法可以改变从资源返回的 bean 的格式,并用正确的格式包装它。但像这样的独特提供商真的是其意图吗?这是实现这三种可能回报的最佳方式吗?

我还想添加到容器响应过滤器类中,我已经必须检查返回的媒体类型并相应地格式化它,但我担心过滤器可能会变得“太大”,因为它也这样做过滤器的作用很大,不确定这是否真的是一个问题。

我也可以只处理构建 bean 并在每个资源方法中相应地对其进行格式化,但是只需执行一次或三次,并将其应用于返回的每个 bean 即可节省时间。

哪个方向比较好?还有其他选择可能比这两个更好吗?

谢谢!

I'm working on an API using Jersey Server. I have a common root element defined in a bean that I currently wrap around the response from the resource (another bean) using a container response filter. It works great.

It basically returns this:

<transaction>
   <status>Good</status>
   <id>1</id>
   ....
</transaction>

So it basically wraps the transaction element and status element around the bean returned from the resource, which is annotated with javax.xml binding annotations.

We're looking at implementing the OData format, which provide an Atom style XML, and JSON. Both are in a different format really. So if the media type requested to be returned is application/xml, the filter works as it does now. If the requested media type is application/atom+xml, it needs to return an atom styled xml document.

<feed xlmns="http://www.w3.org/2005/Atom"
      xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
      xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">
  <title>resource name</title>
  .....
</feed>

If the requested media type is application/JSON it needs to return the JSON format of OData which is something like this:

"d" : {
  "results" : [
  {
    "__metadata": { 
      "uri" : "http://www.url.com/api/resource" 
    },
    "title" : "reource name",
    ....
  ]}
}

I've found online documentation and examples in regards to setting up providers implementing the MessageBodyWriter. I could have one provider for each type. So the produces annotation would have the apporriate media type and the isWriteable method would also check on the appropriate type. Then the writeTo method could alter the format of the bean returned from the resource, and wrap the correct format around it. But is a unique provider like that really the intent and is that the best way to achieve these three possible returns?

I was also thinking of just adding to the container response filter class I already have to check the media type being returned and formatting it accordingly that way, but I worry the filter may get to be "to big", in that it is doing too much for a filter, not sure if that's really a concern.

I could also just handle building the bean up and formatting it accordingly in each resource method, but it would save time to do it once, or three times uniquely, and have that applied to every bean returned.

Which direction is better? Is there another option that may be even better than these two?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

落在眉间の轻吻 2024-12-27 01:10:13

编写自己的 MessageBodyWriter 绝对是正确的方法,因为您有与该格式关联的特定媒体类型,并且您希望以相同的方式处理此类媒体类型的所有请求的序列化。

Writing your own MessageBodyWriter is definitely the right way to go, given you have a specific media type associated with the format and you want to handle the serialization of all the requests for such media type the same way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文