anchor.diff:  			.awaitBody<Person>()
   ----
   
  -When `onStatus` is used, if the response is expected to have content, then the `onStatus`
  -callback should consume it. If not, the content will be automatically drained to ensure
  -resources are released.
  -
   
   
   
   [[webflux-client-exchange]]
  -== `exchange()`
  -
  -The `exchange()` method provides more control than the `retrieve` method. The following example is equivalent
  -to `retrieve()` but also provides access to the `ClientResponse`:
  -
  -[source,java,indent=0,subs="verbatim,quotes",role="primary"]
  -.Java
  -----
  -	Mono<Person> result = client.get()
  -			.uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
  -			.exchange()
  -			.flatMap(response -> response.bodyToMono(Person.class));
  -----
  -[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
  -.Kotlin
  -----
  -	val result = client.get()
  -			.uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
  -			.awaitExchange()
  -			.awaitBody<Person>()
  -----
  -
  -At this level, you can also create a full `ResponseEntity`:
  -
  -[source,java,indent=0,subs="verbatim,quotes",role="primary"]
  -.Java
  -----
  -	Mono<ResponseEntity<Person>> result = client.get()
  -			.uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
  -			.exchange()
  -			.flatMap(response -> response.toEntity(Person.class));
  -----
  -[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
  -.Kotlin
  -----
  -	val result = client.get()
  -			.uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
  -			.awaitExchange()
  -			.toEntity<Person>()
  -----
  -
  -Note that (unlike `retrieve()`), with `exchange()`, there are no automatic error signals for
  -4xx and 5xx responses. You have to check the status code and decide how to proceed.
  -
  -[CAUTION]
  -====
  -Unlike `retrieve()`, when using `exchange()`, it is the responsibility of the application
  -to consume any response content regardless of the scenario (success, error, unexpected
  -data, etc). Not doing so can cause a memory leak. The Javadoc for `ClientResponse` lists
  -all the available options for consuming the body. Generally prefer using `retrieve()`
  -unless you have a good reason for using `exchange()` which does allow to check the
  -response status and headers before deciding how to or if to consume the response.
  -====
  +== `exchangeToMono()`
  +
  +The `exchangeToMono()` and `exchangeToFlux()` methods are useful for more advanced
  +cases that require more control, such as to decode the response differently
  +depending on the response status:
  +
  +[source,java,indent=0,subs="verbatim,quotes",role="primary"]
  +.Java
  +----
  +	Mono<Object> entityMono = client.get()
  +		   .uri("/persons/1")
  +		   .accept(MediaType.APPLICATION_JSON)
  +		   .exchangeToMono(response -> {
  +			   if (response.statusCode().equals(HttpStatus.OK)) {
  +				   return response.bodyToMono(Person.class);
  +			   }
  +			   else if (response.statusCode().is4xxClientError()) {
  +				   return response.bodyToMono(ErrorContainer.class);
  +			   }
  +			   else {
  +				   return Mono.error(response.createException());
  +			   }
  +		   });
  +----
  +[source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
  +.Kotlin
  +----
  +----
  +
  +When using the above, after the returned `Mono` or `Flux` completes, the response body
  +is checked and if not consumed it is released to prevent memory and connection leaks.
  +Therefore the response cannot be decoded further downstream. It is up to the provided
  +function to declare how to decode the response if needed.
  +
   
   
   
  
positive.code: 			.awaitBody<Person>()
  ----
  
  You can also get a stream of objects decoded from the response, as the following example shows:
  
  [source,java,indent=0,subs="verbatim,quotes",role="primary"]
  .Java
  
negative.code: [[webflux-client]]
  = WebClient
  
  Spring WebFlux includes a client to perform HTTP requests with. `WebClient` has a
  functional, fluent API based on Reactor, see <<web-reactive.adoc#webflux-reactive-libraries>>,
  which enables declarative composition of asynchronous logic without the need to deal with
  threads or concurrency. It is fully non-blocking, it supports streaming, and relies on
  the same <<web-reactive.adoc#webflux-codecs, codecs>> that are also used to encode and
  decode request and response content on the server side.
  
  `WebClient` needs an HTTP client library to perform requests with. There is built-in
  support for the following:
  
  * https://github.com/reactor/reactor-netty[Reactor Netty]
  * https://github.com/jetty-project/jetty-reactive-httpclient[Jetty Reactive HttpClient]
  * https://hc.apache.org/index.html[Apache HttpComponents]
  * Others can be plugged via `ClientHttpConnector`.
  
  
  
  