2018-02-27

Web on Reactive Stack(version 5.0.3.RELEASE) 2. WebClientをテキトーに訳した

https://docs.spring.io/spring/docs/5.0.3.RELEASE/spring-framework-reference/web-reactive.html#webflux-client

2. WebClient

spring-webfluxモジュールには、Reactive Streamsのバックプレッシャを用いるHTTPリクエスト用のノンブロッキング・リアクティブなクライアントが含まれます。

このクライアントはHTTP codecsおよびサーバのfunctional web frameworkの基礎部分は共通です。

WebClientはHTTPクライアントライブラリを下側に置く高レベルのAPIです。デフォルトではReactor Nettyを使いますが、別のClientHttpConnectorを使用してプラグイン可能です。WebClient APIは出力にFluxかMonoを返し、入力にReactive StreamsのPublisherを受けます。（Reactive Libraries参照）

RestTemplateと比較すると、WebClientはより関数型でJava 8のラムダを取り入れたfluent APIです。同期・非同期の両方を備え、ストリーミングを含むので、ノンブロッキングI/Oで有用です。

2.1. Retrieve

retrieve()メソッドで簡単にレスポンスボディを取得してデコードできます。

    WebClient client = WebClient.create("http://example.org");

    Mono<Person> result = client.get()
            .uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
            .retrieve()
            .bodyToMono(Person.class);

また、レスポンスからデコードするオブジェクトのストリームを得られます。

    Flux<Quote> result = client.get()
            .uri("/quotes").accept(MediaType.TEXT_EVENT_STREAM)
            .retrieve()
            .bodyToFlux(Quote.class);

デフォルトでは、4xxか5xxのステータスコードのレスポンスはWebClientResponseExceptionのエラーになりますが、これはカスタマイズ可能です。

    Mono<Person> result = client.get()
            .uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
            .retrieve()
            .onStatus(HttpStatus::is4xxServerError, response -> ...)
            .onStatus(HttpStatus::is5xxServerError, response -> ...)
            .bodyToMono(Person.class);

2.2. Exchange

exchange()ではより細かい制御ができます。以下の例はretrieve()と同等ですが、ClientResponseにアクセスしています。

    Mono<Person> result = client.get()
            .uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
            .exchange()
            .flatMap(response -> response.bodyToMono(Person.class));

この段階で、完全なResponseEntityを生成することもできます。

    Mono<ResponseEntity<Person>> result = client.get()
            .uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
            .exchange()
            .flatMap(response -> response.toEntity(Person.class));

retrieve()と異なり、exchange()では、4xxと5xxレスポンスにおける自動的なエラー通知はありません。自前でステータスコードをチェックして続行するかを決めるコードを書く必要があります。

exchange()を使う場合、ClientResponseのtoEntityかbodyメソッドのいずれかを必ず使用してください。これは、リソースを開放してHTTPコネクションプーリングに潜在的な問題を抱えるのを回避するためです。もしレスポンスの中身が無い場合はbodyToMono(Void.class)を使います。ただし、レスポンスの中身がある場合、コネクションは閉じてプールには戻らない点に注意してください。

2.3. Request body

リクエストボディはObjectからエンコードします。

    Mono<Person> personMono = ... ;

    Mono<Void> result = client.post()
            .uri("/persons/{id}", id)
            .contentType(MediaType.APPLICATION_JSON)
            .body(personMono, Person.class)
            .retrieve()
            .bodyToMono(Void.class);

エンコードされたオブジェクトのストリームも使えます。

    Flux<Person> personFlux = ... ;

    Mono<Void> result = client.post()
            .uri("/persons/{id}", id)
            .contentType(MediaType.APPLICATION_STREAM_JSON)
            .body(personFlux, Person.class)
            .retrieve()
            .bodyToMono(Void.class);

値そのままを使う場合、syncBodyというショートカットのメソッドを使います。

    Person person = ... ;

    Mono<Void> result = client.post()
            .uri("/persons/{id}", id)
            .contentType(MediaType.APPLICATION_JSON)
            .syncBody(person)
            .retrieve()
            .bodyToMono(Void.class);

2.3.1. Form data

フォームデータの送信にはボディにMultiValueMap<String, String>を使用します。なお、MultiValueMap<String, String>によって自動的に"application/x-www-form-urlencoded"をセットします。

    MultiValueMap<String, String> formData = ... ;

    Mono<Void> result = client.post()
            .uri("/path", id)
            .syncBody(formData)
            .retrieve()
            .bodyToMono(Void.class);

BodyInsertersでインラインにフォームデータを記述できます。

    import static org.springframework.web.reactive.function.BodyInserters.*;

    Mono<Void> result = client.post()
            .uri("/path", id)
            .body(fromFormData("k1", "v1").with("k2", "v2"))
            .retrieve()
            .bodyToMono(Void.class);

2.3.2. Multipart data

マルチパートデータの送信にはMultiValueMap<String, ?>を使用し、その値には、パートのボディを表すObjectか、パートのボディとヘッダーを表すHttpEntity、のどちらかを使います。パートを作るにはMultipartBodyBuilderを使います。

    MultipartBodyBuilder builder = new MultipartBodyBuilder();
    builder.part("fieldPart", "fieldValue");
    builder.part("filePart", new FileSystemResource("...logo.png"));
    builder.part("jsonPart", new Person("Jason"));

    MultiValueMap<String, HttpEntity<?>> parts = builder.build();

    Mono<Void> result = client.post()
            .uri("/path", id)
            .syncBody(parts)
            .retrieve()
            .bodyToMono(Void.class);

なお、各パートのコンテンツタイプは書き込むファイルの拡張子かObjectの型に基づいて自動設定します。また、各パートごとにコンテンツタイプを明示的に指定することも可能です。

BodyInsertersでインラインにマルチパートデータを記述するやり方もあります。

    import static org.springframework.web.reactive.function.BodyInserters.*;

    Mono<Void> result = client.post()
            .uri("/path", id)
            .body(fromMultipartData("fieldPart", "value").with("filePart", resource))
            .retrieve()
            .bodyToMono(Void.class);

2.4. Builder options

WebClientの生成は簡単で、staticファクトリメソッドcreate()と、すべてのリクエストのベースとなるURLを与えるcreate(String)で行います。WebClient.builder()にはより細かいオプションがあります。

基底のHTTPクライアントをカスタマイズするには以下のようにします。

    SslContext sslContext = ...

    ClientHttpConnector connector = new ReactorClientHttpConnector(
            builder -> builder.sslContext(sslContext));

    WebClient webClient = WebClient.builder()
            .clientConnector(connector)
            .build();

HTTPメッセージのエンコード・デコードで使われるHTTP codecsをカスタマイズするには以下のようにします。

    ExchangeStrategies strategies = ExchangeStrategies.builder()
            .codecs(configurer -> {
                // ...
            })
            .build();

    WebClient webClient = WebClient.builder()
            .exchangeStrategies(strategies)
            .build();

ビルダーはFiltersを追加するのに使用します。

URIの構築やデフォルトヘッダー（とクッキー）などその他のオプションについてはIDEでWebClient.Builderを確認してみてください。

WebClientの作成後は、新しくWebClientを生成するための新しいbuilderを常に取得可能です。元のインスタンスをベースにしますが、現在のインスタンスには何も影響を与えません。

    WebClient modifiedClient = client.mutate()
            // user builder methods...
            .build();

2.5. Filters

WebClient supports interception style request filtering:

    WebClient client = WebClient.builder()
            .filter((request, next) -> {
                ClientRequest filtered = ClientRequest.from(request)
                        .header("foo", "bar")
                        .build();
                return next.exchange(filtered);
            })
            .build();

ExchangeFilterFunctionsはベーシック認証用のフィルターです。

    // static import of ExchangeFilterFunctions.basicAuthentication

    WebClient client = WebClient.builder()
            .filter(basicAuthentication("user", "pwd"))
            .build();

また、オリジナルのインスタンスに影響を与えることなくWebClientインスタンスを変更できます*1。

*1:You can also mutate an existing WebClient instance without affecting the original:が原文。mutateを「変更」と訳すのはだいぶニュアンスが失われているとは思うが、あんま良い日本語浮かばず。

2018-02-27

Web on Reactive Stack(version 5.0.3.RELEASE) 1. Spring WebFluxをテキトーに訳した（1.5 - 1.9）

Java Spring Spring WebFlux テキトー翻訳

1.5. Functional Endpoints

Spring WebFluxには、軽量な関数型プログラミングモデルがあり、関数ではルーティング・リクエスト処理とイミュータブルな設計を行います。アノテーションベースとは別のプログラミングモデルですが、基礎部分で動作するReactive Spring Webは同一です。

1.5.1. HandlerFunction

HTTPリクエストはHandlerFunctionで処理し、これは基本的にはServerRequestを受け取ってMono<ServerResponse>を返す関数です。アノテーションベースを知っているユーザ向けに言えば、ハンドラファクションは@RequestMappingメソッドに相当します。

ServerRequestとServerResponseはイミュータブルなインタフェースで、基底のHTTPメッセージにJDK-8らしいやり方でアクセスを提供します。アクセスはReactive Streamsのノンブロッキングバックプレッシャで行います。リクエストはReactorのFluxもしくはMonoでボディを公開し、レスポンスはボディとしてReactive StreamsのPublisherをアクセプトします。これの合理性についてはReactive Librariesで解説します。

ServerRequestはHTTPリクエストの各種要素、メソッド・URI・クエリパラメータ・ヘッダー（ServerRequest.Headers経由）、へのアクセスを提供します。ボディへのアクセスはbodyメソッドで行います。たとえば、以下はリクエストボディをMono<String>に抽出します。

Mono<String> string = request.bodyToMono(String.class);

また、以下はボディをFluxに抽出する方法で、Personはボディのコンテンツからデシリアライズするクラスです（つまりボディがJSON, JAXB（XMLの場合）を含む場合PersonクラスはJacksonが処理する）。

Flux<Person> people = request.bodyToFlux(Person.class);

上述のbodyToMonoとbodyToFluxはジェネリックなServerRequest.body(BodyExtractor)メソッドを使用する便利なメソッドです。BodyExtractorは関数型のストラテジインタフェースで、自前の抽出ロジックを書くものですが、一般的なBodyExtractorのインスタンスは```BodyExtractors````ユーティリティクラスにあります。よって、上記サンプルは以下のようにも書けます。

Mono<String> string = request.body(BodyExtractors.toMono(String.class);
Flux<Person> people = request.body(BodyExtractors.toFlux(Person.class);

同様に、ServerResponseはHTTPレスポンスへのアクセスを提供します。これはイミュータブルなので、ビルダーでServerResponseを生成します。ビルダーで、レスポンスステータス・レスポンスヘッダーの追加・ボディの指定、が出来ます。たとえば、レスポンスを、200 OKステータス・JSONコンテンツタイプ・ボディ指定、で作るには以下のようにします。

Mono<Person> person = ...
ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).body(person);

また、以下は、201 CREATEDステータス・"Location"ヘッダー・空のボディ、のレスポンスを作ります。

URI location = ...
ServerResponse.created(location).build();

HandlerFunctionをこれらを使用して作れます。たとえば、以下はごく単純な"Hello World"なラムダのハンドラーで、200 ステータス・ボディにString、のレスポンスを返します。

HandlerFunction<ServerResponse> helloWorld =
  request -> ServerResponse.ok().body(fromObject("Hello World"));

上述のように、ラムダでハンドラ関数を簡単に書けますが、場合によっては可読性を損なうので、複数の関数がある場合はメンテナンス性が悪くなります。よって、単一のハンドラかコントローラに、関連するハンドラ関数をグループ化することを推奨します。たとえば、以下はreactiveのPersonリポジトリを公開するクラスです。

import static org.springframework.http.MediaType.APPLICATION_JSON;
import static org.springframework.web.reactive.function.BodyInserters.fromObject;

public class PersonHandler {

    private final PersonRepository repository;

    public PersonHandler(PersonRepository repository) {
        this.repository = repository;
    }

    public Mono<ServerResponse> listPeople(ServerRequest request) { // 1.
        Flux<Person> people = repository.allPeople();
        return ServerResponse.ok().contentType(APPLICATION_JSON).body(people, Person.class);
    }

    public Mono<ServerResponse> createPerson(ServerRequest request) { // 2.
        Mono<Person> person = request.bodyToMono(Person.class);
        return ServerResponse.ok().build(repository.savePerson(person));
    }

    public Mono<ServerResponse> getPerson(ServerRequest request) { // 3.
        int personId = Integer.valueOf(request.pathVariable("id"));
        Mono<ServerResponse> notFound = ServerResponse.notFound().build();
        Mono<Person> personMono = repository.getPerson(personId);
        return personMono
                .flatMap(person -> ServerResponse.ok().contentType(APPLICATION_JSON).body(fromObject(person)))
                .switchIfEmpty(notFound);
    }
}

listPeopleはJSONでリポジトリのすべてのPersionオブジェクトを返します。
createPersonはリクエストボディ内のPersionを新規作成します。PersonRepository.savePerson(Person)はMono<Void>を返す点に注意してください。personがリクエストから読み込まれて保存されると、空のMonoは完了シグナルを出します。完了シグナル受信時、つまりPerson保存完了時、にレスポンスを送信するにはbuild(Publisher<Void>)を使うことになります。
getPersonはパス変数にIDを指定して単一のpersonを返すハンドラー関数です。リポジトリからPersonを取得し、もし存在すればJSONレスポンスを生成します。無ければ、switchIfEmpty(Mono<T>)で404 Not Foundレスポンスを返しています。

1.5.2. RouterFunction

リクエストはRouterFunctionがハンドラー関数にルーティングします。RouterFunctionの関数はServerRequestを受け取ってMono<HandlerFunction>を返します。リクエストがある特定のルーティングにマッチするとハンドラ関数が返され、マッチしない場合は空のMonoが返されます。アノテーションベースを知っているユーザ向けに言えば、RouterFunctionは@RequestMappingアノテーションに相当します。

基本的には、ルータ―関数を自身で書くことはありませんが、リクエスト述語とハンドラ関数でルータ関数を生成するにはRouterFunctions.route(RequestPredicate, HandlerFunction)を使います。述語が適用可能な場合、そのリクエストはハンドラー関数にルーティングが行われ、そうでない場合ルーティングは実行されず、404 Not Foundレスポンスが返されます。自前のRequestPredicateを書くことは可能ですが、そうする必要は無く、良くある一般的な述語はRequestPredicatesユーティリティクラスにあり、例えば、パスペース・HTTPメソッド・コンテンツタイプなどでのマッチングです。routeを使用する、"Hello World"なハンドラ―関数へのルーティングの記述は以下のようになります。

RouterFunction<ServerResponse> helloWorldRoute =
    RouterFunctions.route(RequestPredicates.path("/hello-world"),
    request -> Response.ok().body(fromObject("Hello World")));

二つのルータ関数を一つの複合ルータ関数にまとめることが出来ます。最初のルーティングの述語にマッチしない場合、二つ目が評価されます。複合ルータ関数はそれぞれ順に評価されるので、狭い述語を先に置き、より汎用の述語を後に置きます。RouterFunction.and(RouterFunction)かRouterFunction.andRoute(RequestPredicate, HandlerFunction)で二つのルータ関数を複合化します。後者はRouterFunction.and()とRouterFunctions.route()を組み合わせて一度にやるものです。

上述したPersonHandlerを例にとると、個々のハンドラへのルータ関数は以下のように定義します。ハンドラ関数の参照はメソッド参照を使用しています。

import static org.springframework.http.MediaType.APPLICATION_JSON;
import static org.springframework.web.reactive.function.server.RequestPredicates.*;

PersonRepository repository = ...
PersonHandler handler = new PersonHandler(repository);

RouterFunction<ServerResponse> personRoute =
    route(GET("/person/{id}").and(accept(APPLICATION_JSON)), handler::getPerson)
        .andRoute(GET("/person").and(accept(APPLICATION_JSON)), handler::listPeople)
        .andRoute(POST("/person").and(contentType(APPLICATION_JSON)), handler::createPerson);

ルータ関数では、RequestPredicate.and(RequestPredicate)かRequestPredicate.or(RequestPredicate)で、リクエスト述語の組み合わせを指定しています。これらの動作は見た目ままで、andは与えられた述語が両方ともマッチした場合で、orはどちらかです。RequestPredicatesの述語の多くが複合になっています。たとえば、RequestPredicates.GET(String)はRequestPredicates.method(HttpMethod)とRequestPredicates.path(String)の複合です。

1.5.3. Running a server

HTTPサーバでのルータ関数の動かし方について。最もシンプルなやり方はルータ関数を以下のいずれかの手段でHttpHandlerに変換します。

RouterFunctions.toHttpHandler(RouterFunction)
RouterFunctions.toHttpHandler(RouterFunction, HandlerStrategies)

戻り値のHttpHandlerは各種サーバ固有のアダプタで使用可能で、以下のHttpHandlerに示す通りです。

別の方法として、WebFlux Configを使用するDispatcherHandlerベースのセットアップで動かす方法があります。WebFlux Configはリクエスト処理に必要となるコンポーネントを宣言するのにSpring configurationを使用します。WebFlux Java configは以下のファンクショナルエンドポイント用の基盤コンポーネントを宣言します。

RouterFunctionMapping - Spring configurationで一つ以上のRouterFunction<?>を検出すると、それらをRouterFunction.andOtherで複合化し、出来たRouterFunctionにリクエストをルーティングする。
HandlerFunctionAdapter - リクエストにマッピングされているHandlerFunctionをDispatcherHandlerが呼び出すためのシンプルなアダプタ。
ServerResponseResultHandler - HandlerFunctionの呼び出し結果をServerResponseのwriteToを呼び出すことで処理する。

上述のコンポーネントはDispatcherHandlerのリクエスト処理ライフサイクルにファンクショナルエンドポイントをフィットさせるためのもので、同時に、アノテーションのコントローラがもし存在すればこれと並存させるためのものでもあります。また、Spring Boot WebFlux starterがファンクショナルエンドポイントを有効化する方法でもあります。

以下はWebFlux Java configの例です。（動かし方はDispatcherHandler参照）

@Configuration
@EnableWebFlux
public class WebConfig implements WebFluxConfigurer {

    @Bean
    public RouterFunction<?> routerFunctionA() {
        // ...
    }

    @Bean
    public RouterFunction<?> routerFunctionB() {
        // ...
    }

    // ...

    @Override
    public void configureHttpMessageCodecs(ServerCodecConfigurer configurer) {
        // configure message conversion...
    }

    @Override
    default void addCorsMappings(CorsRegistry registry) {
        // configure CORS...
    }

    @Override
    public void configureViewResolvers(ViewResolverRegistry registry) {
        // configure view resolution for HTML rendering...
    }
}

1.5.4. HandlerFilterFunction

ルータ関数でマッピングしたルーティングはRouterFunction.filter(HandlerFilterFunction)でフィルタをかけられます。HandlerFilterFunctionはServerRequestとHandlerFunctionを受け取りServerResponseを返す関数です。このハンドラ関数の引数はチェーンの次の要素で、基本的にはルーティング先のHandlerFunctionですが、複数のフィルタが適用される場合は別のFilterFunctionになる場合があります。アノテーションベースの類似機能は@ControllerAdvice and/or ServletFilterで実現できます。いま、ルーティングにセキュリティフィルタを追加するとして、特定のパスが許可されるかどうかを判定するSecurityManagerが既にあるとします。

import static org.springframework.http.HttpStatus.UNAUTHORIZED;

SecurityManager securityManager = ...
RouterFunction<ServerResponse> route = ...

RouterFunction<ServerResponse> filteredRoute =
    route.filter((request, next) -> {
        if (securityManager.allowAccessTo(request.path())) {
            return next.handle(request);
        }
        else {
            return ServerResponse.status(UNAUTHORIZED).build();
        }
  });

上記の例にあるようにnext.handle(ServerRequest)は必ずしも呼ぶ必要はありません。上記ではアクセスを許可する場合にだけハンドラ関数を呼び出しています。

ファンクショナルエンドポイントでのCORSはCorsWebFilterで行っています。

Controller method argument	Description
`ServerWebExchange`	`ServerWebExchange`のフルアクセス。このクラスは、HTTPリクエスト・レスポンス・リクエストとセッション属性・`checkNotModified`メソッド、などのコンテナ
`ServerHttpRequest`, `ServerHttpResponse`	HTTPリクエストやレスポンスへのアクセス用
`WebSession`	セッションへのアクセス用。属性が追加されない限り、新規セッションの開始を強制しない。reactive型サポート対象。
`java.security.Principal`	現在の認証済みユーザ。基本的には既知の`Principal`実装になる。reactive型サポート対象。
`org.springframework.http.HttpMethod`	リクエストのHTTPメソッド
`java.util.Locale`	使用可能な中で最も特定的な`LocaleResolver`で決定される現在のリクエストのロケール。
Java 6+: `java.util.TimeZone` Java 8+: `java.time.ZoneId`	`LocaleContextResolver`が決定する現在のリクエストに関連付けられたタイムゾーン。
`@PathVariable`	URIテンプレート変数へのアクセス用。URI Patterns参照。
`@MatrixVariable`	URIパスセグメント内のname-valueペアへのアクセス用。Matrix variables
`@RequestParam`	Servletリクエストパラメータへのアクセス用。パラメータ値はメソッド引数の型に変換される。@RequestParamを参照。属性の設定には`@RequestParam`以外の方法もあります。この表の"Any other argument"も参照。
`@RequestHeader`	リクエストヘッダ―へのアクセス用。ヘッダー値はメソッド引数の型に変換される。@RequestHeader
`@CookieValue`	クッキーへのアクセス用。クッキーの値はメソッド引数の型に変換される。@CookieValue
`@RequestBody`	HTTPリクエストボディへのアクセス用。ボディコンテンツは`HttpMessageReader`を使用するメソッド引数の型に変換される。reactive型サポート対象。
`HttpEntity<B>`	リクエストヘッダ―とボディへのアクセス用。ボディは`HttpMessageReader`に変換される。reactive型サポート対象。
`@RequestPart`	"multipart/form-data"リクエストのpart部分へのアクセス用。reactive型サポート対象。MultipartとMultipart Readerを参照。
`java.util.Map`, `org.springframework.ui.Model`, `org.springframework.ui.ModelMap`	HTMLコントローラーおよびビューのテンプレートで使うモデルへのアクセス用。
`@ModelAttribute`	モデル（無ければインスタンス化される）の属性へのアクセス用。データバインディングとvalidationが適用される。@ModelAttribute, Model Methods, Binder Methodsを参照。属性の設定には`@ModelAttribute`以外の方法もあります。この表の"Any other argument"も参照。
`Errors`, `BindingResult`	command object（`@ModelAttribute`引数のこと）のvalidationとデータバインディングのエラー、もしくは、`@RequestBody`もしくは`@RequestPart`のvalidationエラー。`Errors`や`BindingResult`はvalidation対象メソッド引数の直後に宣言する必要がある。
`SessionStatus` + クラスレベル`@SessionAttributes`	あるフォーム処理の完了時に、クラスレベルの`@SessionAttributes`で宣言したセッション属性のクリーンアップを指示する。@SessionAttributesを参照。
`UriComponentsBuilder`	相対URLを現在のリクエストのホスト・ポート・スキーマ・コンテキストパスを考慮したものにする。サーブレットマッピングのリテラルパートは`Forwarded`と`X-Forwarded-*`ヘッダーに入る。
`@SessionAttribute`	任意のセッション属性へのアクセス用。クラスレベルの`@SessionAttributes`宣言でセッションに持たせるモデル属性以外のセッション属性にもアクセスできます。
`@RequestAttribute`	リクエスト属性へのアクセス用。@RequestAttributeを参照。
その他	メソッド引数が上記いずれにもマッチしない場合、デフォルトでは、BeanUtils#isSimplePropertyに該当する単純な型の場合は`@RequestParam`に解決される。そうでない場合は`@ModelAttribute`になる。

Controller method return value	Description
`@ResponseBody`	`HttpMessageWriter`でエンコードしてレスポンスに書き込まれる。@ResponseBody参照。
`HttpEntity<B>`, `ResponseEntity<B>`	`HttpMessageWriter`でエンコードするボディとHTTPヘッダーを含む完全なレスポンス。ResponseEntity参照。
`HttpHeaders`	ボディ無しでヘッダーを持つレスポンスを返す。
`String`	`ViewResolver`で解決するビュー名で、command objectsと`@ModelAttribute`のメソッドが決定する暗黙モデルで使用される*3。ハンドラメソッドでは`Model`引数を宣言してモデルを使用します（上記参照）。
`View`	暗黙モデルと一緒にレンダリングに使う`View`インスタンス。ハンドラメソッドでは`Model`引数を宣言してモデルを使用します（上記参照）。
`java.util.Map`, `org.springframework.ui.Model`	暗黙モデルに追加される属性。ビュー名はリクエストパスに基づいて暗黙的に決定される。
`@ModelAttribute`	モデルに追加される属性。ビュー名はリクエストパスに基づいて暗黙的に決定される。 `@ModelAttribute`の使用は任意です。この表の「それ以外の戻り値」を参照。
`Rendering`	モデルとビューをレンダリングするシナリオ用のAPI。
`void`	`void`のメソッドは、おそらく非同期（`Mono<Void>`など）で、`ServerHttpResponse`・ `ServerWebExchange`引数・`@ResponseStatus`のいずれかの場合、戻り値型（もしくは`null`）はレスポンスを完全に処理したと見なします。コントローラーがpositive ETagかlastModifiedタイムスタンプチェックを行う場合も同様に扱われます。上記いずれにも当てはまらない場合、`void`はRESTコントローラーでは"no response body"を意味し、HTMLコントローラーではデフォルトのビュー名になります。
`Flux<ServerSentEvent>`, `Observable<ServerSentEvent>`, その他のReactive型	server-sentイベントの送出。データを書き込む必要がある場合のみ、`SeverSentEvent`ラッパーは省略可能です。（ただし、`text/event-stream`は、リクエストするか、属性のプロデュース経由でマッピングに宣言する必要があります。*4）
それ以外の戻り値	上記いずれにも該当しない場合、デフォルトでは、`String`か`void`の場合ビュー名として扱われます（voidはデフォルトビュー名が適用）。また、BeanUtils#isSimplePropertyに該当する単純な型でない場合はモデルに追加される属性になります。それ以外はunresolvedのままです。

2. WebClient

2.1. Retrieve

2.2. Exchange

2.3. Request body

2.3.1. Form data

2.3.2. Multipart data

2.4. Builder options

2.5. Filters

1.5. Functional Endpoints

1.5.1. HandlerFunction

1.5.2. RouterFunction

1.5.3. Running a server

1.5.4. HandlerFilterFunction

1.6. CORS

1.6.1. Introduction

1.6.2. Processing

1.6.3. @CrossOrigin

1.6.4. Global Config

1.6.5. CORS WebFilter

1.7. Web Security

1.8. WebFlux Config

1.8.1. Enable WebFlux config

1.8.2. WebFlux config API

1.8.3. Conversion, formatting

1.8.4. Validation

1.8.5. Content type resolvers

1.8.6. HTTP message codecs

1.8.7. View resolvers

1.8.8. Static resources

1.8.9. Path Matching

1.8.10. Advanced config mode

1.9. HTTP/2

1.4. Annotated Controllers

1.4.1. @Controller

1.4.2. Request Mapping

URI Patterns

Pattern Comparison

Consumable Media Types

Producible Media Types

Parameters and Headers

HTTP HEAD, OPTIONS

1.4.3. Handler methods

Method arguments

Return values

Type Conversion

Matrix variables

@RequestParam

@RequestHeader

@CookieValue

@ModelAttribute

@SessionAttributes

@SessionAttribute

@RequestAttribute

Multipart

@RequestBody

HttpEntity

@ResponseBody

ResponseEntity

Jackson JSON

Jackson serialization views

1.4.4. Model Methods

1.4.5. Binder Methods

1.4.6. Controller Advice