函数参数使用Mono<T>与Flux<T>的场景及REST调用差异咨询

Great question! Reactive types like Mono<T> and Flux<T> aren’t just for return values—using them as parameters is a deliberate choice tied to reactive programming’s core goals of non-blocking, asynchronous processing. Let’s break this down.

Key Use Cases for Reactive Parameters #

1. Your Parameter Comes From an Asynchronous Source #

If the input value itself is fetched asynchronously (e.g., from another reactive service, a Redis cache, or a message queue), passing a Mono<T> lets you chain operations without blocking. Instead of calling .block() to extract the value (which defeats the purpose of reactive programming), you can directly compose the parameter into your reactive pipeline.

Example:

// Fetch last name from an async user profile service
Mono<String> asyncLastName = userProfileService.getAuthenticatedUserLastName();

// Pass the Mono directly to avoid blocking
userRepository.findByLastName(asyncLastName)
               .flatMap(user -> notificationService.sendWelcomeAlert(user))
               .subscribe();

2. Handling Optional Parameters Safely #

Mono<T> explicitly represents a value that may or may not exist (0 or 1 elements), which is far safer than using null for optional inputs. You can use operators like defaultIfEmpty() or switchIfEmpty() to handle missing values gracefully within the reactive chain.

3. Processing Stream/Batch Inputs #

If your method needs to handle multiple input values (e.g., a list of last names to search for), Flux<T> lets you process them as a stream. This is especially useful for large datasets where loading all values into memory at once would be inefficient—you can process elements one at a time with backpressure support.

4. Maintaining a Fully Reactive Pipeline #

In a fully reactive application (like one built with Spring WebFlux), using reactive parameters ensures your entire workflow remains non-blocking. Avoiding blocking calls to extract values keeps your application scalable, as threads aren’t tied up waiting for input data.

REST Interface Differences: Reactive vs. Primitive Parameters #

When exposing your method via a REST endpoint, using Mono<String> instead of a plain String changes how the request is handled:

1. Request Binding Behavior #

• Plain String: Typically bound to @RequestParam (URL query parameter) or @PathVariable (URL path segment). The framework will block until the parameter is parsed and available before invoking your method.
• Mono<String>: Can be bound to:
  • @RequestBody: Accepts the entire request body as an asynchronous single value (useful for JSON payloads containing just the last name).
  • @RequestParam(required = false): Handles optional query parameters gracefully—if the parameter is missing, the Mono will be empty instead of throwing a missing parameter error.

Example REST endpoints:

// Plain String as required query parameter
@GetMapping("/users")
Flux<User> findByLastName(@RequestParam String lastName) {
    return userRepository.findByLastName(Mono.just(lastName));
}

// Mono<String> as optional query parameter
@GetMapping("/users")
Flux<User> findByLastName(@RequestParam(required = false) Mono<String> lastName) {
    // Fallback to "Smith" if no last name is provided
    return lastName.defaultIfEmpty("Smith")
                   .flatMapMany(userRepository::findByLastName);
}

// Mono<String> as request body
@PostMapping("/users/search")
Flux<User> searchByLastName(@RequestBody Mono<String> lastName) {
    return userRepository.findByLastName(lastName);
}

2. Non-Blocking vs. Blocking Execution #

• With a plain String parameter, the framework waits for the parameter to be fully parsed before calling your method—this is a blocking step.
• With Mono<String>, your method is invoked immediately, and the actual parameter processing happens asynchronously. The reactive chain only proceeds when the Mono emits a value, keeping your application’s threads free to handle other requests.

3. Error Handling Flexibility #

• For plain String parameters, errors (like missing required parameters or invalid formats) are thrown before your method runs—you’ll need to handle them with global exception handlers.
• For Mono<String>, you can handle errors directly in the reactive chain using operators like onErrorResume() or onErrorReturn(), giving you granular control over how invalid inputs are processed.

4. Backpressure Support (for Flux<T>) #

If you use Flux<String> as a parameter (e.g., accepting a stream of last names in the request body), you get built-in backpressure support. This means your service can control the rate at which it receives data from the client, preventing memory overload when dealing with large datasets. Plain List<String> parameters require loading all data into memory upfront, which isn’t scalable for large inputs.

Quick Summary #

Use reactive parameters when:

• Your input is asynchronous or optional
• You need to process streaming/batch data
• You want to maintain a fully non-blocking pipeline

Use primitive types like String when:

• The parameter is a simple, required value from the URL
• You’re working in a non-reactive context (though this defeats the purpose of using Reactor!)

内容的提问来源于stack exchange，提问作者Bibek Shakya