MessageBodyReaders 是如何使用的答案

【问题标题】：How are MessageBodyReaders usedMessageBodyReaders 是如何使用的
【发布时间】：2014-07-13 12:29:03
【问题描述】：

鉴于类似：

例如

class User{
  String name;
  String someField1;
}

 @Consumes("some/media-type")
class ResourceA{

    public Response test(@FormParam("u") User u, @FormParam("f) String someField){
    }
}

几个问题：

将单个MessageBodyReader 用于反序列化User 还是将用户中的每个字段由不同的阅读器反序列化？
任何/所有这些都需要@context？
User 类中的字段是否需要 @FormParam？

我试图了解服务器是否会获取可用阅读器的列表，并且对于测试中的每个参数，检查是否有任何阅读器可以反序列化该类型。或者，如果第一个与所使用的媒体类型匹配的读取器预计会反序列化所有参数。

如果服务器正在遍历每个参数并为每个参数找到最合适的读取器，那么传递给readFrom 的输入流是同一个实例是有道理的，并且每个读取器都在通过输入流前进.是这种情况还是我完全误解了MessageBodyReader 的使用方式？

【问题讨论】：

标签： java rest servlets jersey-2.0 dropwizard

【解决方案1】：

查看此文档以了解如何使用 entity providers are selected。特别是：

程序 7.2。 MessageBodyReader 选择算法

获取请求的媒体类型。如果请求不包含一个 Content-Type 标头，然后使用 application/octet-stream 媒体类型。

标识其值将被映射的参数的 Java 类型从实体主体。服务器上的 Java 类型是资源方法的实体参数。在客户端它是类传递给 readFrom 方法。

选择一组可用的 MessageBodyReader 提供程序支持请求的媒体类型。

遍历选定的 MessageBodyReader 类，并且，利用他们的 isReadable 方法，选择第一个支持所需组合的 MessageBodyReader 提供程序 Java 类型/媒体类型/注解参数。

如果第 4 步找到合适的 MessageBodyReader，则使用它的 readFrom 方法将实体主体映射到所需的 Java 类型。

否则，服务器运行时必须生成 NotSupportedException （HTTP 415 状态码）并且没有实体和客户端运行时必须生成一个 ProcessingException 的实例。

@Context 不是必需的，@FormParam 不需要添加到您的 bean - 只需添加到 REST 资源方法。

【讨论】：

谢谢，我还在规范中发现它回答了部分问题。 @ 987654322@ - 我的误解出现在#4，它说选择第一个，但听起来这意味着单个参数的第一个。如果资源接受多个参数，它是否从 1 开始重复？我想是的，但我不确定。不清楚的第二件事是输入流，如果它从一个重复，流位置是保持不变（这将是有意义的）还是重置为 0（意义不大）。但这对我来说并不完全清楚

【解决方案2】：

看来它像我想象的那样有效。查看 RESTEasy 的源代码，MethodInjectorImpl 类使用具有输入流的相同请求实例。对于每个参数，注入器都会发现最合适的读取器。

输入流不会被触及，而是由每个解析请求值的读取器推进。

【讨论】：