为什么我的 Web 服务为大多数移动浏览器生成 XML 结果而不是 HTML 结果？
我有一个 Restful Web 服务资源，我已为其定义了 XML 和 HTML 方法。对于桌面浏览器，该服务可以准确地生成 HTML，而对于我编写的 Android 客户端，该服务可以准确地生成 XML。
然而，当涉及到移动浏览器时，该服务会生成 XML，而它应该生成 HTML。
一种方法注释为
@Produces({MediaType.TEXT_HTML})
，另一种方法注释为
@Produces({MediaType.APPLICATION_XML})
是否需要查看 Accept 标头以外的内容才能获得所需的结果？
更新：从移动浏览器请求中拦截的可接受的媒体类型为：
INFO: application/xml
INFO: application/xhtml+xml
INFO: image/png
INFO: text/html; q=0.9
信息：文本/纯文本； q=0.8
信息：/； q=0.5
I have a restful web service resource for which I've defined both XML and HTML methods. For desktop browsers the service accurately produces HTML, and for the Android client I've written it accurately produces XML.
When it comes to mobile browsers however, the service produces XML, where it should produce HTML.
One method is annotated with
@Produces({MediaType.TEXT_HTML})
And the other with
@Produces({MediaType.APPLICATION_XML})
Do I need to look at more than the Accept header to get the desired result?
Update: The acceptable media types, intercepted from the mobile browser request, are:
INFO: application/xml
INFO: application/xhtml+xml
INFO: image/png
INFO: text/html; q=0.9
INFO: text/plain; q=0.8
INFO: /; q=0.5
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这篇文章解释了基于 webkit 的浏览器（大多数移动浏览器）如何），而且 IE 显然也使用接受标头，将 XML 优先于 HTML。基于此和此 所以问题，最好不要仅仅依赖于请求的接受标头，而是将其与 URL 指定的表示结合起来。
另一种解决方案是通过将质量属性附加到 @Produces 声明来覆盖客户端的 Accept 首选项。如果您使 qs 大于 1：
浏览器客户端的首选项将被覆盖。然后，对于有需要的客户端，您必须为客户端上的其他内容类型设置更大的 qs 值。我不知道这种方法是否是好的做法，但这就是我所采用的。
This post explains how browsers based on webkit (most mobile browsers), and apparently also IE use accept headers that prioritize XML over HTML. Based on that and this SO question, it seems better to not to rely solely on the accept header of the request, but instead combine it with URL-specified representation.
Another solution is to override the Accept preference of the client by appending a quality attribute to the @Produces declaration. If you make qs larger than 1:
the preferences of the browser clients will be overridden. Then you will have to make the qs value even larger for other content types on the client side for clients that require that. I don't know if this approach is good practice, but it's what I went with.