Question

给出类似的东西：

e.g。

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吗？
@FormParam班级的字段是否需要User

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

如果服务器正在迭代每个参数，并且每个参数找到最合适的读者，那么传递给readFrom的输入流是同一个实例是有意义的，并且每个读者都在推进输入流。是这种情况还是我完全误解了MessageBodyReader是如何使用的？

Answer 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资源方法。

Answer 2

它似乎有效，我怀疑。查看RESTEasy的源代码，MethodInjectorImpl类使用具有输入流的同一请求实例。对于每个参数，进样器会发现最合适的读数器。

未触及输入流，并且每个读取器都会对输入流进行处理，该读取器会解析请求中的值。

如何使用MessageBodyReaders

2 个答案: