関数エンドポイント

Spring WebFlux には、WebFlux.fn が含まれています。WebFlux.fn は、機能を使用してリクエストのルーティングと処理を行い、契約は不変性のために設計されています。これは、アノテーションベースのプログラミングモデルに代わるものですが、それ以外は同じリアクティブコア基盤で実行されます。

概要

サーブレットスタックに相当する部分を参照

WebFlux.fn では、HTTP リクエストは HandlerFunction で処理されます。ServerRequest を受け取り、遅延された ServerResponse （つまり Mono<ServerResponse>）を返す関数です。リクエストオブジェクトとレスポンスオブジェクトの両方に、HTTP リクエストとレスポンスへの JDK 8 フレンドリーなアクセスを提供する不変の契約があります。HandlerFunction は、アノテーションベースのプログラミングモデルの @RequestMapping メソッドの本体に相当します。

受信リクエストは、RouterFunction を使用してハンドラー関数にルーティングされます: ServerRequest を受け取り、遅延 HandlerFunction （つまり Mono<HandlerFunction>）を返す関数。ルーター関数が一致すると、ハンドラー関数が返されます。それ以外の場合は、空の Mono。RouterFunction は @RequestMapping アノテーションと同等ですが、ルーター関数がデータだけでなく動作も提供するという大きな違いがあります。

RouterFunctions.route() は、次の例に示すように、ルーターの作成を容易にするルータービルダーを提供します。

  • Java

  • Kotlin

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

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

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


public class PersonHandler {

	// ...

	public Mono<ServerResponse> listPeople(ServerRequest request) {
		// ...
	}

	public Mono<ServerResponse> createPerson(ServerRequest request) {
		// ...
	}

	public Mono<ServerResponse> getPerson(ServerRequest request) {
		// ...
	}
}
1route() を使用してルーターを作成します。
val repository: PersonRepository = ...
val handler = PersonHandler(repository)

val route = coRouter { (1)
	accept(APPLICATION_JSON).nest {
		GET("/person/{id}", handler::getPerson)
		GET("/person", handler::listPeople)
	}
	POST("/person", handler::createPerson)
}


class PersonHandler(private val repository: PersonRepository) {

	// ...

	suspend fun listPeople(request: ServerRequest): ServerResponse {
		// ...
	}

	suspend fun createPerson(request: ServerRequest): ServerResponse {
		// ...
	}

	suspend fun getPerson(request: ServerRequest): ServerResponse {
		// ...
	}
}
1 コルーチンルーター DSL を使用してルーターを作成します。router { } を介してリアクティブな代替も使用できます。

RouterFunction を実行する 1 つの方法は、RouterFunction を HttpHandler に変換し、組み込みサーバーアダプターの 1 つを介してインストールすることです。

  • RouterFunctions.toHttpHandler(RouterFunction)

  • RouterFunctions.toHttpHandler(RouterFunction, HandlerStrategies)

ほとんどのアプリケーションは、WebFlux Java 構成を介して実行できます。サーバーの実行を参照してください。

HandlerFunction

サーブレットスタックに相当する部分を参照

ServerRequest および ServerResponse は、HTTP リクエストおよびレスポンスへの JDK 8 フレンドリーなアクセスを提供する不変のインターフェースです。リクエストとレスポンスの両方が、ボディストリームに対する Reactive Streams (英語) バックプレッシャーを提供します。リクエスト本体は、Reactor Flux または Mono で表されます。レスポンス本体は、Flux および Mono を含む Reactive Streams Publisher で表されます。詳細については、リアクティブライブラリを参照してください。

ServerRequest

ServerRequest は HTTP メソッド、URI、ヘッダー、クエリパラメーターへのアクセスを提供し、ボディへのアクセスは body メソッドを介して提供されます。

次の例では、リクエストの本文を Mono<String> に抽出します。

  • Java

  • Kotlin

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

次の例では、本文を Flux<Person> （または Kotlin の Flow<Person>）に抽出します。ここで、Person オブジェクトは、JSON や XML などの直列化された形式からデコードされます。

  • Java

  • Kotlin

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

上記の例は、より一般的な ServerRequest.body(BodyExtractor) を使用するショートカットであり、BodyExtractor 機能戦略インターフェースを受け入れます。ユーティリティクラス BodyExtractors は、多数のインスタンスへのアクセスを提供します。例: 上記の例は、次のように書くこともできます。

  • Java

  • Kotlin

Mono<String> string = request.body(BodyExtractors.toMono(String.class));
Flux<Person> people = request.body(BodyExtractors.toFlux(Person.class));
	val string = request.body(BodyExtractors.toMono(String::class.java)).awaitSingle()
	val people = request.body(BodyExtractors.toFlux(Person::class.java)).asFlow()

次の例は、フォームデータにアクセスする方法を示しています。

  • Java

  • Kotlin

Mono<MultiValueMap<String, String>> map = request.formData();
val map = request.awaitFormData()

次の例は、マップとしてマルチパートデータにアクセスする方法を示しています。

  • Java

  • Kotlin

Mono<MultiValueMap<String, Part>> map = request.multipartData();
val map = request.awaitMultipartData()

次の例は、マルチパートデータに 1 つずつストリーミング方式でアクセスする方法を示しています。

  • Java

  • Kotlin

Flux<PartEvent> allPartEvents = request.bodyToFlux(PartEvent.class);
allPartsEvents.windowUntil(PartEvent::isLast)
      .concatMap(p -> p.switchOnFirst((signal, partEvents) -> {
          if (signal.hasValue()) {
              PartEvent event = signal.get();
              if (event instanceof FormPartEvent formEvent) {
                  String value = formEvent.value();
                  // handle form field
              }
              else if (event instanceof FilePartEvent fileEvent) {
                  String filename = fileEvent.filename();
                  Flux<DataBuffer> contents = partEvents.map(PartEvent::content);
                  // handle file upload
              }
              else {
                  return Mono.error(new RuntimeException("Unexpected event: " + event));
              }
          }
          else {
              return partEvents; // either complete or error signal
          }
      }));
val parts = request.bodyToFlux<PartEvent>()
allPartsEvents.windowUntil(PartEvent::isLast)
    .concatMap {
        it.switchOnFirst { signal, partEvents ->
            if (signal.hasValue()) {
                val event = signal.get()
                if (event is FormPartEvent) {
                    val value: String = event.value();
                    // handle form field
                } else if (event is FilePartEvent) {
                    val filename: String = event.filename();
                    val contents: Flux<DataBuffer> = partEvents.map(PartEvent::content);
                    // handle file upload
                } else {
                    return Mono.error(RuntimeException("Unexpected event: " + event));
                }
            } else {
                return partEvents; // either complete or error signal
            }
        }
    }
}

PartEvent オブジェクトの本体の内容は、メモリリークを回避するために、完全に消費、中継、解放する必要があることに注意してください。

ServerResponse

ServerResponse は HTTP レスポンスへのアクセスを提供します。これは不変なので、build メソッドを使用して HTTP レスポンスを作成できます。ビルダーを使用して、レスポンスステータスを設定したり、レスポンスヘッダーを追加したり、本文を提供したりできます。次の例では、JSON コンテンツで 200（OK）レスポンスを作成します。

  • Java

  • Kotlin

Mono<Person> person = ...
ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).body(person, Person.class);
val person: Person = ...
ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).bodyValue(person)

次の例は、Location ヘッダーを持ち、本文がない 201（CREATED）レスポンスを作成する方法を示しています。

  • Java

  • Kotlin

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

使用されるコーデックに応じて、ヒントパラメーターを渡して、本体の直列化または逆直列化の方法をカスタマイズできます。例: Jackson JSON ビュー (英語) を指定するには:

  • Java

  • Kotlin

ServerResponse.ok().hint(Jackson2CodecSupport.JSON_VIEW_HINT, MyJacksonView.class).body(...);
ServerResponse.ok().hint(Jackson2CodecSupport.JSON_VIEW_HINT, MyJacksonView::class.java).body(...)

ハンドラークラス

次の例に示すように、ハンドラー関数をラムダとして記述できます。

  • Java

  • Kotlin

HandlerFunction<ServerResponse> helloWorld =
  request -> ServerResponse.ok().bodyValue("Hello World");
val helloWorld = HandlerFunction<ServerResponse> { ServerResponse.ok().bodyValue("Hello World") }

これは便利ですが、アプリケーションでは複数の関数が必要であり、複数のインラインラムダが乱雑になる可能性があります。関連するハンドラー関数を、アノテーションベースのアプリケーションの @Controller と同様のロールを持つハンドラークラスにグループ化すると便利です。例: 次のクラスは、リアクティブ Person リポジトリを公開します。

  • Java

  • Kotlin

import static org.springframework.http.MediaType.APPLICATION_JSON;
import static org.springframework.web.reactive.function.server.ServerResponse.ok;

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 ok().contentType(APPLICATION_JSON).body(people, Person.class);
	}

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

	public Mono<ServerResponse> getPerson(ServerRequest request) { (3)
		int personId = Integer.valueOf(request.pathVariable("id"));
		return repository.getPerson(personId)
			.flatMap(person -> ok().contentType(APPLICATION_JSON).bodyValue(person))
			.switchIfEmpty(ServerResponse.notFound().build());
	}
}
1listPeople は、リポジトリで見つかったすべての Person オブジェクトを JSON として返すハンドラー関数です。
2createPerson は、リクエスト本文に含まれる新しい Person を保存するハンドラー関数です。PersonRepository.savePerson(Person) は Mono<Void> を返すことに注意してください。空の Mono は、リクエストから人が読み取られて保管されたときに完了シグナルを発行します。そのため、build(Publisher<Void>) メソッドを使用して、完了信号を受信したとき（つまり、Person が保存されたとき）にレスポンスを送信します。
3getPerson は、id パス変数で識別される 1 人の人物を返すハンドラー関数です。Person をリポジトリから取得し、見つかった場合は JSON レスポンスを作成します。見つからない場合は、switchIfEmpty(Mono<T>) を使用して 404 未検出レスポンスを返します。
class PersonHandler(private val repository: PersonRepository) {

	suspend fun listPeople(request: ServerRequest): ServerResponse { (1)
		val people: Flow<Person> = repository.allPeople()
		return ok().contentType(APPLICATION_JSON).bodyAndAwait(people);
	}

	suspend fun createPerson(request: ServerRequest): ServerResponse { (2)
		val person = request.awaitBody<Person>()
		repository.savePerson(person)
		return ok().buildAndAwait()
	}

	suspend fun getPerson(request: ServerRequest): ServerResponse { (3)
		val personId = request.pathVariable("id").toInt()
		return repository.getPerson(personId)?.let { ok().contentType(APPLICATION_JSON).bodyValueAndAwait(it) }
				?: ServerResponse.notFound().buildAndAwait()

	}
}
1listPeople は、リポジトリで見つかったすべての Person オブジェクトを JSON として返すハンドラー関数です。
2createPerson は、リクエスト本文に含まれる新しい Person を保存するハンドラー関数です。PersonRepository.savePerson(Person) は、戻り値のない一時停止関数であることに注意してください。
3getPerson は、id パス変数で識別される 1 人の人物を返すハンドラー関数です。Person をリポジトリから取得し、見つかった場合は JSON レスポンスを作成します。見つからない場合、404 未検出レスポンスを返します。

検証

関数エンドポイントは、Spring の検証機能を使用して、リクエスト本文に検証を適用できます。例: Person のカスタム Spring バリデーター実装がある場合:

  • Java

  • Kotlin

public class PersonHandler {

	private final Validator validator = new PersonValidator(); (1)

	// ...

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

	private void validate(Person person) {
		Errors errors = new BeanPropertyBindingResult(person, "person");
		validator.validate(person, errors);
		if (errors.hasErrors()) {
			throw new ServerWebInputException(errors.toString()); (3)
		}
	}
}
1Validator インスタンスを作成します。
2 検証を適用します。
3400 レスポンスに対して例外を発生させます。
class PersonHandler(private val repository: PersonRepository) {

	private val validator = PersonValidator() (1)

	// ...

	suspend fun createPerson(request: ServerRequest): ServerResponse {
		val person = request.awaitBody<Person>()
		validate(person) (2)
		repository.savePerson(person)
		return ok().buildAndAwait()
	}

	private fun validate(person: Person) {
		val errors: Errors = BeanPropertyBindingResult(person, "person");
		validator.validate(person, errors);
		if (errors.hasErrors()) {
			throw ServerWebInputException(errors.toString()) (3)
		}
	}
}
1Validator インスタンスを作成します。
2 検証を適用します。
3400 レスポンスに対して例外を発生させます。

ハンドラーは、LocalValidatorFactoryBean に基づいてグローバル Validator インスタンスを作成および注入することにより、標準 Bean 検証 API（JSR-303）を使用することもできます。Spring 検証を参照してください。

RouterFunction

サーブレットスタックに相当する部分を参照

ルーター関数を使用して、リクエストを対応する HandlerFunction にルーティングします。通常、ルーター関数は自分で作成するのではなく、RouterFunctions ユーティリティクラスのメソッドを使用して作成します。RouterFunctions.route() （パラメーターなし）は、ルーター関数を作成するための流れるようなビルダーを提供しますが、RouterFunctions.route(RequestPredicate, HandlerFunction) はルーターを直接作成する方法を提供します。

通常、route() ビルダーを使用することをお勧めします。これは、検出が困難な静的インポートを必要とせずに、一般的なマッピングシナリオに便利なショートカットを提供するためです。たとえば、ルーター関数ビルダーは、GET リクエストのマッピングを作成するメソッド GET(String, HandlerFunction) を提供します。POST 用の POST(String, HandlerFunction)。

HTTP メソッドベースのマッピングに加えて、ルートビルダーは、リクエストにマッピングするときに追加の述語を導入する方法を提供します。HTTP メソッドごとに、RequestPredicate をパラメーターとして受け取るオーバーロードされたバリアントがありますが、追加の制約を表現できます。

述語

独自の RequestPredicate を作成できますが、RequestPredicates ユーティリティクラスは、リクエストパス、HTTP メソッド、コンテンツ型などに基づいて、一般的に使用される実装を提供します。次の例では、リクエスト述語を使用して、Accept ヘッダーに基づいて制約を作成します。

  • Java

  • Kotlin

RouterFunction<ServerResponse> route = RouterFunctions.route()
	.GET("/hello-world", accept(MediaType.TEXT_PLAIN),
		request -> ServerResponse.ok().bodyValue("Hello World")).build();
val route = coRouter {
	GET("/hello-world", accept(TEXT_PLAIN)) {
		ServerResponse.ok().bodyValueAndAwait("Hello World")
	}
}

以下を使用して、複数のリクエスト述語を一緒に作成できます。

  • RequestPredicate.and(RequestPredicate) — 両方が一致する必要があります。

  • RequestPredicate.or(RequestPredicate) — どちらも一致できます。

RequestPredicates の述語の多くが構成されています。例: RequestPredicates.GET(String) は RequestPredicates.method(HttpMethod) と RequestPredicates.path(String) から構成されています。上記の例では、ビルダーが RequestPredicates.GET を内部で使用し、それを accept 述語で構成しているため、2 つのリクエスト述語も使用しています。

ルート

ルーターの機能は順番に評価されます。最初のルートが一致しない場合、2 番目のルートが評価されます。一般的なルートの前に、より具体的なルートを宣言することは理にかなっています。これは、後で説明するように、ルーター関数を Spring Bean として登録する場合にも重要です。この動作は、「最も具体的な」コントローラーメソッドが自動的に選択されるアノテーションベースのプログラミングモデルとは異なることに注意してください。

ルーター関数ビルダーを使用する場合、定義されたすべてのルートは、build() から返される 1 つの RouterFunction に構成されます。複数のルーター関数を一緒に構成する他の方法もあります。

  •  RouterFunctions.route() ビルダーの add(RouterFunction) 

  • RouterFunction.and(RouterFunction)

  • RouterFunction.andRoute(RequestPredicate, HandlerFunction) —  RouterFunctions.route() をネストした RouterFunction.and() のショートカット。

次の例は、4 つのルートの構成を示しています。

  • Java

  • Kotlin

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> otherRoute = ...

RouterFunction<ServerResponse> route = route()
	.GET("/person/{id}", accept(APPLICATION_JSON), handler::getPerson) (1)
	.GET("/person", accept(APPLICATION_JSON), handler::listPeople) (2)
	.POST("/person", handler::createPerson) (3)
	.add(otherRoute) (4)
	.build();
1 JSON に一致する Accept ヘッダーを持つ GET /person/{id} は PersonHandler.getPerson にルーティングされます
2 JSON に一致する Accept ヘッダーを持つ GET /person は PersonHandler.listPeople にルーティングされます
3 追加の述語のない POST /person は PersonHandler.createPerson にマップされます
4otherRoute は、他の場所で作成され、構築されたルートに追加されるルーター関数です。
import org.springframework.http.MediaType.APPLICATION_JSON

val repository: PersonRepository = ...
val handler = PersonHandler(repository);

val otherRoute: RouterFunction<ServerResponse> = coRouter {  }

val route = coRouter {
	GET("/person/{id}", accept(APPLICATION_JSON), handler::getPerson) (1)
	GET("/person", accept(APPLICATION_JSON), handler::listPeople) (2)
	POST("/person", handler::createPerson) (3)
}.and(otherRoute) (4)
1 JSON に一致する Accept ヘッダーを持つ GET /person/{id} は PersonHandler.getPerson にルーティングされます
2 JSON に一致する Accept ヘッダーを持つ GET /person は PersonHandler.listPeople にルーティングされます
3 追加の述語のない POST /person は PersonHandler.createPerson にマップされます
4otherRoute は、他の場所で作成され、構築されたルートに追加されるルーター関数です。

ネストされたルート

ルーター関数のグループが共有述語（共有パスなど）を持つことは一般的です。上記の例では、共有述語は、3 つのルートで使用される /person に一致するパス述語になります。アノテーションを使用する場合、/person にマップする型レベルの @RequestMapping アノテーションを使用して、この重複を削除します。WebFlux.fn では、経路述語は、ルーター関数ビルダーの path メソッドを介して共有できます。たとえば、上記の例の最後の数行は、ネストされたルートを使用して次のように改善できます。

  • Java

  • Kotlin

RouterFunction<ServerResponse> route = route()
	.path("/person", builder -> builder (1)
		.GET("/{id}", accept(APPLICATION_JSON), handler::getPerson)
		.GET(accept(APPLICATION_JSON), handler::listPeople)
		.POST(handler::createPerson))
	.build();
1path の 2 番目のパラメーターは、ルータービルダーを使用するコンシューマーであることに注意してください。
val route = coRouter { (1)
	"/person".nest {
		GET("/{id}", accept(APPLICATION_JSON), handler::getPerson)
		GET(accept(APPLICATION_JSON), handler::listPeople)
		POST(handler::createPerson)
	}
}
1 コルーチンルーター DSL を使用してルーターを作成します。router { } を介してリアクティブな代替も使用できます。

パスベースのネストが最も一般的ですが、Builder で nest メソッドを使用して、あらゆる種類の述語にネストできます。上記には、共有 Accept -header 述語の形式での重複がまだ含まれています。nest メソッドと accept を併用すると、さらに改善できます。

  • Java

  • Kotlin

RouterFunction<ServerResponse> route = route()
	.path("/person", b1 -> b1
		.nest(accept(APPLICATION_JSON), b2 -> b2
			.GET("/{id}", handler::getPerson)
			.GET(handler::listPeople))
		.POST(handler::createPerson))
	.build();
val route = coRouter {
	"/person".nest {
		accept(APPLICATION_JSON).nest {
			GET("/{id}", handler::getPerson)
			GET(handler::listPeople)
			POST(handler::createPerson)
		}
	}
}

リソースの提供

WebFlux.fn は、リソースを提供するための組み込みサポートを提供します。

以下で説明する機能に加えて、RouterFunctions#resource(java.util.function.Function) (Javadoc) のおかげでさらに柔軟なリソース処理を実装することができます。

リソースへのリダイレクト

指定された述語に一致するリクエストをリソースにリダイレクトできます。これは、たとえば、シングルページアプリケーションでリダイレクトを処理する場合に役立ちます。

  • Java

  • Kotlin

ClassPathResource index = new ClassPathResource("static/index.html");
List<String> extensions = Arrays.asList("js", "css", "ico", "png", "jpg", "gif");
RequestPredicate spaPredicate = path("/api/**").or(path("/error")).or(pathExtension(extensions::contains)).negate();
RouterFunction<ServerResponse> redirectToIndex = route()
	.resource(spaPredicate, index)
	.build();
val redirectToIndex = router {
	val index = ClassPathResource("static/index.html")
	val extensions = listOf("js", "css", "ico", "png", "jpg", "gif")
	val spaPredicate = !(path("/api/**") or path("/error") or
		pathExtension(extensions::contains))
	resource(spaPredicate, index)
}

ルートの場所からリソースを提供する

特定のパターンに一致するリクエストを、特定のルートの場所に関連するリソースにルーティングすることもできます。

  • Java

  • Kotlin

Resource location = new FileSystemResource("public-resources/");
RouterFunction<ServerResponse> resources = RouterFunctions.resources("/resources/**", location);
val location = FileSystemResource("public-resources/")
val resources = router { resources("/resources/**", location) }

サーバーの実行

サーブレットスタックに相当する部分を参照

HTTP サーバーでルーター関数をどのように実行しますか？ 簡単なオプションは、次のいずれかを使用して、ルーター関数を HttpHandler に変換することです。

  • RouterFunctions.toHttpHandler(RouterFunction)

  • RouterFunctions.toHttpHandler(RouterFunction, HandlerStrategies)

その後、サーバー固有の手順について HttpHandler に従うことにより、返された HttpHandler を多数のサーバーアダプターで使用できます。

Spring Boot でも使用されるより一般的なオプションは、WebFlux 構成を介して DispatcherHandler ベースのセットアップで実行することです。WebFlux 構成は、Spring 構成を使用して、リクエストの処理に必要なコンポーネントを宣言します。WebFlux Java 構成は、関数エンドポイントをサポートするために次のインフラストラクチャコンポーネントを宣言します。

  • RouterFunctionMapping: Spring 構成内の 1 つ以上の RouterFunction<?> Bean を検出し、順序付け、RouterFunction.andOther を介してそれらを結合し、結果として作成された RouterFunction にリクエストをルーティングします。

  • HandlerFunctionAdapter: DispatcherHandler がリクエストにマップされた HandlerFunction を呼び出せるようにする単純なアダプター。

  • ServerResponseResultHandler: ServerResponse の writeTo メソッドを呼び出すことにより、HandlerFunction の呼び出しからの結果を処理します。

上記のコンポーネントにより、関数エンドポイントは DispatcherHandler リクエスト処理ライフサイクルに適合し、アノテーション付きコントローラー（存在する場合）と並行して（潜在的に）実行されます。また、Spring Boot WebFlux スターターが関数エンドポイントを有効にする方法でもあります。

次の例は、WebFlux Java 構成を示しています（実行方法については、DispatcherHandler を参照してください）。

  • Java

  • Kotlin

@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
	public void addCorsMappings(CorsRegistry registry) {
		// configure CORS...
	}

	@Override
	public void configureViewResolvers(ViewResolverRegistry registry) {
		// configure view resolution for HTML rendering...
	}
}
@Configuration
@EnableWebFlux
class WebConfig : WebFluxConfigurer {

	@Bean
	fun routerFunctionA(): RouterFunction<*> {
		// ...
	}

	@Bean
	fun routerFunctionB(): RouterFunction<*> {
		// ...
	}

	// ...

	override fun configureHttpMessageCodecs(configurer: ServerCodecConfigurer) {
		// configure message conversion...
	}

	override fun addCorsMappings(registry: CorsRegistry) {
		// configure CORS...
	}

	override fun configureViewResolvers(registry: ViewResolverRegistry) {
		// configure view resolution for HTML rendering...
	}
}

ハンドラー関数のフィルタリング

サーブレットスタックに相当する部分を参照

ルーティング関数ビルダーで before、after、filter メソッドを使用して、ハンドラー関数をフィルター処理できます。アノテーションを使用すると、@ControllerAdvice、ServletFilter、その両方を使用して同様の機能を実現できます。フィルターは、ビルダーによって作成されたすべてのルートに適用されます。これは、ネストされたルートで定義されたフィルターが「トップレベル」ルートに適用されないことを意味します。たとえば、次の例について考えてみます。

  • Java

  • Kotlin

RouterFunction<ServerResponse> route = route()
	.path("/person", b1 -> b1
		.nest(accept(APPLICATION_JSON), b2 -> b2
			.GET("/{id}", handler::getPerson)
			.GET(handler::listPeople)
			.before(request -> ServerRequest.from(request) (1)
				.header("X-RequestHeader", "Value")
				.build()))
		.POST(handler::createPerson))
	.after((request, response) -> logResponse(response)) (2)
	.build();
1 カスタムリクエストヘッダーを追加する before フィルターは、2 つの GET ルートにのみ適用されます。
2 レスポンスを記録する after フィルターは、ネストされたものを含むすべてのルートに適用されます。
val route = router {
	"/person".nest {
		GET("/{id}", handler::getPerson)
		GET("", handler::listPeople)
		before { (1)
			ServerRequest.from(it)
					.header("X-RequestHeader", "Value").build()
		}
		POST(handler::createPerson)
		after { _, response -> (2)
			logResponse(response)
		}
	}
}
1 カスタムリクエストヘッダーを追加する before フィルターは、2 つの GET ルートにのみ適用されます。
2 レスポンスを記録する after フィルターは、ネストされたものを含むすべてのルートに適用されます。

ルータービルダーの filter メソッドは HandlerFilterFunction を取ります。これは、ServerRequest と HandlerFunction を取り、ServerResponse を返す関数です。ハンドラー関数パラメーターは、チェーンの次の要素を表します。これは通常、ルーティング先のハンドラーですが、複数が適用される場合は別のフィルターにすることもできます。

特定のパスが許可されているかどうかを判断できる SecurityManager があると仮定して、ルートに簡単なセキュリティフィルターを追加できます。次の例は、その方法を示しています。

  • Java

  • Kotlin

SecurityManager securityManager = ...

RouterFunction<ServerResponse> route = route()
	.path("/person", b1 -> b1
		.nest(accept(APPLICATION_JSON), b2 -> b2
			.GET("/{id}", handler::getPerson)
			.GET(handler::listPeople))
		.POST(handler::createPerson))
	.filter((request, next) -> {
		if (securityManager.allowAccessTo(request.path())) {
			return next.handle(request);
		}
		else {
			return ServerResponse.status(UNAUTHORIZED).build();
		}
	})
	.build();
val securityManager: SecurityManager = ...

val route = router {
		("/person" and accept(APPLICATION_JSON)).nest {
			GET("/{id}", handler::getPerson)
			GET("", handler::listPeople)
			POST(handler::createPerson)
			filter { request, next ->
				if (securityManager.allowAccessTo(request.path())) {
					next(request)
				}
				else {
					status(UNAUTHORIZED).build();
				}
			}
		}
	}

上記の例は、next.handle(ServerRequest) の呼び出しがオプションであることを示しています。アクセスが許可されている場合にのみハンドラー関数を実行させます。

ルーター関数ビルダーで filter メソッドを使用する以外に、RouterFunction.filter(HandlerFilterFunction) を介して既存のルーター関数にフィルターを適用することができます。

関数エンドポイントの CORS サポートは、専用の CorsWebFilter を介して提供されます。