在Spring Webflux中,ResponseEntity
什么时候最合适?
在此问题之后,假设我需要返回一个列表,或者说Foo的几个元素,有很多返回Flux的示例。
返回ResponseEntity
寻找此问题时,我发现了以下相同的问题:https://github.com/spring-projects/spring-framework/issues/22614,但没有答案,我搜索了spring文档,但没有找到信息。
感谢您的帮助。
答案 0 :(得分:3)
以下是您可以使用 ResponseEntity
返回值进行的各种选择:
ResponseEntity<Mono<T>>
或 ResponseEntity<Flux<T>>
-- 这使得响应状态和标题立即已知,而主体在稍后异步提供。正文是 Mono
还是 Flux
取决于响应有多少个值。Mono<ResponseEntity<T>>
-- 这提供了所有三个 -- 响应状态、标头和正文,稍后异步提供。 IT 允许响应状态和标头根据异步请求处理的结果而变化。Mono<ResponseEntity<Mono<T>>>
或 Mono<ResponseEntity<Flux<T>>>
也是可能的,但不太常见。它们首先异步提供响应状态和标头,然后提供响应正文,稍后也在第二个点异步提供。答案 1 :(得分:0)
WebFlux支持使用单值反应类型来生成 ResponseEntity异步和/或单值和多值反应 身体的类型。
因此,带注释的控制器上的返回类型实际上是Reactive Publisher,例如Flux或Mono,它会发出表示要返回的数据的对象。
示例
Flux<AccountDto>
或者:
Flux<ResponseEntity<AccountDto>>
我认为您甚至可以将原始DTO类型设置为返回类型,Webflux会自动为您将其包装在发布者中。
有效的返回类型
非阻塞式反应范例
进行反应式编程时,您希望每个层都通过Flux / Mono进行通信。因此,您将从ReactiveRepository中获取磁通,并且服务层还将磁通返回给控制器。基本上,在反应式编程中,所有内容都是Flux / Mono。
内部
虽然SpringMVC和Spring Webflux注释的控制器看起来很相似,但它们在内部却有很大的不同。例如,默认情况下,Webflux使用Jetty,而SpringMVC使用Tomcat。在内部,Webflux更像是一种非阻塞事件循环体系结构,而SpringMVC传统上利用每个请求的1个线程阻塞一个I / O的线程池。
查看本文,了解有关Spring WebFlux
的更多详细信息