Spring Webflux控制器返回Mono<ResponseEntity<MyPojo>>相较Mono<MyPojo>的优势
Mono<ResponseEntity<MyPojo>>相比Mono<MyPojo>的核心优势 灵活自定义HTTP状态码
直接返回Mono<MyPojo>时,Spring Webflux默认会给成功响应绑定200状态码,要修改状态码只能通过@ResponseStatus注解或者抛出ResponseStatusException实现,动态适配场景非常麻烦。而ResponseEntity支持按需指定任意状态码,比如创建资源返回201、查询资源不存在返回404、参数校验失败返回400,完全匹配RESTful规范的语义要求,代码实现也更直观。
示例代码:public Mono<ResponseEntity<MyPojo>> createPojo(MyPojo pojo) { return repository.insert(pojo) .map(savedPojo -> ResponseEntity.status(HttpStatus.CREATED).body(savedPojo)); }可灵活配置响应头
很多业务场景需要自定义响应头,比如创建资源后返回Location头指向资源地址、配置Cache-Control控制缓存策略、添加业务自定义头(比如分页场景的X-Total-Count),ResponseEntity的Builder模式可以非常方便的添加任意响应头,直接返回Mono<MyPojo>很难优雅实现这类需求。空值/异常场景处理更直观
当业务逻辑返回空结果时,直接返回Mono<MyPojo>的默认行为不一定符合预期,比如单查接口没有对应数据时,我们需要返回404而不是200空响应,用ResponseEntity可以直接通过defaultIfEmpty方法封装404响应,不需要额外抛出异常或者配置全局处理逻辑,代码可读性更强。
示例代码:public Mono<ResponseEntity<MyPojo>> getPojoById(String id) { return repository.findById(id) .map(ResponseEntity::ok) .defaultIfEmpty(ResponseEntity.notFound().build()); }适配无响应体的场景
对于删除、更新这类不需要返回响应体的接口,你可以直接返回Mono<ResponseEntity<Void>>,比如删除成功返回204无内容,语义更明确,不需要为了适配返回类型构造无意义的POJO对象。
当然如果是逻辑非常简单、不需要自定义状态码和响应头的接口,直接返回Mono<MyPojo>的代码更简洁,可以根据业务场景按需选择。
内容的提问来源于stack exchange,提问作者PatPanda

