从 Jersey 迁移到 RESTEasy 时内容类型为空。

Question

因此，我编写了一个示例 REST 资源，它在 Jersey/Tomcat 中的工作方式就像一个魅力，但当我将它带到 RestEASY/Tomcat 时，它就崩溃了。我的意思是真的吗？开箱即用的工作发生了什么？总之有点沮丧。尝试访问资源时出现此错误(http://localhost:7070/mg/mytest )

“content-type 为 null 并期望提取正文”

7842 [http-7070-2] 错误 com.loyalty.mg.rest.exception.MGExceptionMapper - 异常映射器中捕获的错误 - org.jboss.resteasy.spi.BadRequestException：内容类型为空并期望提取正文 在 org.jboss.resteasy.core.MessageBodyParameterInjector.inject（MessageBodyParameterInjector.java:131） 在 org.jboss.resteasy.core.MethodInjectorImpl.injectArguments（MethodInjectorImpl.java:98） 在 org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:121) 在 org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:247) 在 org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:212) 在 org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:202)

@Path("/mytest")
public class TestResource  {

    @GET
    public Response getData()

我想问题也是 - RestEASY 比 Jersey 更好吗，这只是开始，我遇到了错误。我应该坚持选择泽西岛吗？

也已经尝试过这个了:)

<context-param>
  <param-name>resteasy.media.type.mappings</param-name>
  <param-value>json : application/json, xml : application/xml</param-value> 
</context-param>

Answer 1

RestEASY vs Jersey 很难说：
http://www.infoq.com/news/2008/10/jaxrs-比较

关于您的错误，您可以通过注释控制内容类型，如果您放置 @Produces 注解，例如：

@Produces("application/json")
@GET
public Response getData() {
  ...
}

Answer 2

嗯，我知道这个请求已经过时了，而且互联网上有很多旧的东西......在两年的时间里，一切通常都会改变并且工作得更好。因此，与其他非专有 RESTLET 框架相比，RestEasy 应该不会受到不好的评价。

实际上，我认为 JBoss RestEasy 的占用空间最轻，它没有因不必要的 *.jar 而变得臃肿，灵活，经过完全认证的 JAX-RS 实现，完整，并且其易用性是无与伦比的。

有些人回避说，GET 请求不应期望请求中包含 Content_Type（我同意），但是对于每个 GET 请求，都必须表明您打算发送回请求者的内容？正确的！ （是 JSON、XML、纯文本、XML 和工作表、多部分等）。 RestEasy，JBoss 的框架通过如下所示的注释解决了这个问题，并且可以根据 URL REST 请求进行配置。 因此，这就是你的答案

 @GET 
 @Path("/echo/{message}")  
 @Produces("text/plain")  
 public String echo(@PathParam("message")String message){  
     return message;      
 }  

 @GET 
 @Path("/employees")  
 @Produces("application/xml")  
 @Stylesheet(type="text/css", href="${basepath}foo.xsl")
 public List<Employee> listEmployees(){  
    return new ArrayList<Employee>(employees.values());  
 }  

 @GET 
 @Path("/employee/{employeeid}")  
 @Produces("application/xml")  
 public Employee getEmployee(@PathParam("employeeid")String employeeId){  
     return employees.get(employeeId);          
 }  

 @GET 
 @Path("/json/employees/")  
 **@Produces("application/json")**  
 public List<Employee> listEmployeesJSON(){  
     return new ArrayList<Employee>(employees.values());  
}   

Answer 3

GET 请求不得有正文，并且应用程序不得需要 Content-Type 标头。

如果这是 RestEASY 的一个错误，那么人们就会想知道有多少人真正在使用该软件。

编辑

RFC2616 $4.3

消息正文不得包含在
如果规格的请求
请求方法（第 5.1.1 节）
不允许发送实体主体
请求。

服务器应该读取并转发
任何请求的消息正文；如果
请求方法不包括
实体主体的定义语义，
那么消息正文应该是
处理请求时被忽略。

GET 方法不“不允许在请求中发送实体主体”，因此 GET 请求可以有主体。但是 GET “不包括实体主体的定义语义”，因此无论如何主体都应该被忽略。

无论如何，RestEASY 不应该要求 GET 请求中存在 Content-Type。

Answer 4

引发该异常的代码如下所示：

     final MediaType mediaType = request.getHttpHeaders().getMediaType();
     if (mediaType == null) {
        throw new BadRequestException(
             "content-type was null and expecting to extract a body");
     }

问题似乎是 RestEASY 无法从它收到的请求的标头中找出内容类型。这表明请求中的内容类型是伪造的，或者您配置 RestEASY 的方式存在问题。

我想问题也是 - RestEASY 比 Jersey 更好吗？这只是开始，我遇到了错误。我应该只选择泽西岛吗？

我无法回答这个问题。然而，我认为您太快地将可能是您代码的错误的事情归咎于 RestEASY。

Answer 5

造成这种情况的一个典型原因是，如果您有这样的代码：

@GET
@Path("/foo/{bar}")
@Produces(MediaType.TEXT_HTML)
public Response foo(@PathParam("bar") String bar) {

...并且您忘记使用 @PathParam 注释 bar 参数。然后 RestEasy 认为它应该从请求正文中读取 bar，而不是从 URL 路径中读取，并将抛出此异常。

这似乎不是你的情况发生的情况，但我也遇到了同样的异常，这就是原因。