Spring 5 新功能：功能性 Web 框架

英文原文：New in Spring 5: Functional Web Framework
就像在昨天Juergen发布的博客的一样，Spring 5.0框架第二个里程碑版本中介绍了一个新的功能性web框架。在这篇章中，我将更详细的介绍这个框架。
紧记该功能性web框架是在Spring5.0第一个里程碑版本基础上构建的。并且我们依旧提供基于注解的请求处理（例如
@Controller , @RequestMapping )，关于基于注解的请求处理部分的相关信息请查阅关于Spring5.0第一个里程碑版博客。
示例
我们选用示例程序作为开始。下面是一个响应资源库用于暴露Person 对象。这个响应资源库与传统的无响应资源库似，除了Flux<Person> 对应传统的List<Person> ， Mono<Person> 对应传统的Person 对象。Mono<Void>
完成标识：用于指示保存工作完成.更多Reactor 类型信息请查阅 Dave发布的博客
这里我们介绍如何使用新的功能性web框架暴露资源库：
这里我们介绍如何运行它，下面是Reactor Netty的示例：
最后要做的是，进行一次尝试请求：
上面的介绍覆盖了很多内容，下面让我们深入挖掘下！
核心组件
我将通过依次介绍HandlerFunction,RouterFunction以及FilterFunction 等核心组件来介绍整个框架。这三个接口以文中其他类型都可以在org.springframework.web.reactive.function包中找到。
处理功能
新框架的起点是HandlerFunction<T>，其实质是Function<Request, Response<T>>，其中的Request 和 Response
1234
public interface PersonRepository {
Mono<Person> getPerson(int id);
Flux<Person> allPeople();
Mono<Void> savePerson(Mono<Person> person);}

RouterFunction<?> route = route(GET("/person/{id}"),
request -> {
Mono<Person> person = Mono.justOrEmpty(request.pathVariable("id"))
.map(Integer::valueOf)
.then(repository::getPerson);
return Response.ok().body(fromPublisher(person, Person.class));
})
.and(route(GET("/person"),
request -> {
Flux<Person> people = repository.allPeople();
return Response.ok().body(fromPublisher(people, Person.class));
}))
.and(route(POST("/person"),
request -> {
Mono<Person> person = request.body(toMono(Person.class));
return Response.ok().build(repository.savePerson(person));
}));

HttpHandler httpHandler = RouterFunctions.toHttpHandler(route);
ReactorHttpHandlerAdapter adapter =
new ReactorHttpHandlerAdapter(httpHandler);
HttpServer server = HttpServer.create("localhost", 8080);
server.startAndAwait(adapter);

$ curl '
{"name":"John Doe","age":42}

都是新定义的不可变接口，提供了基础的对JDK8优化的HTTP消息描述DSL。有一个便捷的构造Response实例的构造与ResponseEntity中的十分相似。注解方式中与HandlerFunction相对应的是@RequestMapping所注解的方法。
如下是“Hello World”的处理方法，它返回了状态为200，body为字符串的消息。
如上，构建于Reactor之上的处理方法是完全的响应式的（reactive），它们可以接受Flux、Mono或者其他相应流
（Reactive Streams）的发布者作为返回类型的参数。
需要注意的是处理方法本身是没有副作用的，因为它将response作为返回值，而不是作为参数（对比
Servlet.service(ServletRequest,ServletResponse)，其实质是BiConsumer<ServletRequest,ServletResponse>）。副作用的方法有很多好处：更有利于测试、构建和优化。
路由功能
入站请求是由RouterFunction<T>，(即Function<Request, Optional<HandlerFunction<T>>)路由到
HandlerFunction中去的。当满足条件匹配时，路由方法会执行处理方法，否则会返回一个空结果。路由方法与
@RequestMapping注解的作用相似。但是，还有一个显著的区别：用注解时路由会被限制到注解的value所能表达的围，处理这些方法的覆盖是困难的；当用路由方法的时候，代码就在那里，可以轻松的覆盖或替换。
如下是一个路由方法的例子，包含了一个行内的处理方法。这里看起来有一点冗余，不必担心，因为后面我们将会将它得精简。
一般不用写完整的路由方法，而是静态引入RouterFunctions.route()，这样就可以用请求判断式（RequestPredicate）
(即 Predicate<Request>)和处理方法（HandlerFunction）创建路由方法了。如果判断式判断成功则返回处理方法，则返回空结果。如下是用route方法方式重写上面的例子：
静态引入RequestPredicates.*后就可以使用那些常用的判断式了，如匹配路径、HTTP方法、content-type等。这样上的例子将会变得更精简：
组合功能
两个路由方法可以被组合成一个新的路由方法，可以路由任意处理方法：如果第一个路由不匹配则执行第二个。可以通调用RouterFunction.and()方法实现，如下：
上面的例子如果路径匹配/hello-world会返回“Hello World”，如果匹配/the-answer则返回“42”。如果都不匹配返回一个空的Optional对象。注意，组合的路由是按顺序执行的，所以应该将更通用的方法放到更明确的方法的前面。

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

RouterFunction<String> helloWorldRoute =
request -> {
if (request.path().equals("/hello-world")) {
return Optional.of(r -> Response.ok().body(fromObject("Hello World")));
} else {
return Optional.empty();
}
};

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

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

RouterFunction<?> route =
route(path("/hello-world"),
request -> Response.ok().body(fromObject("Hello World")))
.and(route(path("/the-answer"),
request -> Response.ok().body(fromObject("42"))));

请求判断式也是可以组合的，通过调研and或者or方法。正如预期的一样：and表示给定的两个判断式同时满足则组合断式满足，or则表示任意判断式满足。如下：
实际上，RequestPredicates中的大部分判断式都是组合的！比如RequestPredicates.GET(String)是
RequestPredicates.method(HttpMethod)和RequestPredicates.path(String)的组合。所以上面的例子可以重写为：
方法引用
此外，目前为止我们的处理方法都是行内的lambda表达式。尽管这样很适合于实例和简短的例子，但是当结合请求路和请求处理两个关注点时，可能就有变“混乱”的趋势了。所以我们将尝试将他们简化。首先，创建一个包含处理逻辑类：
注意，这两个方法的签名都是和处理方法兼容的。这样就可以方法引用了：
过滤功能
由路由器函数进行映射的路由可以通过调用 RouterFunction.filter(FilterFunction<T, R>) 来进行过滤, 这里的
FilterFunction<T,R> 其实就是一个 BiFunction<Request, HandlerFunction<T>, Response<R>>。函数的处理器
（handler）参数代表的就是整个链条中的下一项: 这是一个典型的 HandlerFunction, 但如果附加了多个过滤器的话，它也是另外的一个 FilterFunction。让我们向路由添加一个日志过滤器：
注意这里对下一个处理器的调用时可选的。这个在安全或者缓存的场景中是很有用的 (例如只在用户拥有足够的权限时才调用
next)。
因为 route 是一个没有被绑定的路由器函数，我们就得知道接下来的处理会返回什么类型的响应消息。这就是为什么我们在器中要以一个 Response<?> 结束, 那样它就会可能有一个 String 类型的响应消息体。我们可以通过使用
RouterFunction.andSame() 而不是 and() 来完成这件事情。这个组合方法要求路由器函数参数是同一个类型。例如，我们让所有的响应消息变成小写的文本形式:

RouterFunction<?> route =
route(method(HttpMethod.GET).and(path("/hello-world")),
request -> Response.ok().body(fromObject("Hello World")))
.and(route(method(HttpMethod.GET).and(path("/the-answer")),
request -> Response.ok().body(fromObject("42"))));

RouterFunction<?> route =
route(GET("/hello-world"),
request -> Response.ok().body(fromObject("Hello World")))
.and(route(GET("/the-answer"),
request -> Response.ok().body(fromObject(42))));

class DemoHandler {
public Response<String> helloWorld(Request request) {
return Response.ok().body(fromObject("Hello World"));
}p
ublic Response<String> theAnswer(Request request) {
return Response.ok().body(fromObject("42"));
}}

DemoHandler handler = new DemoHandler(); // or obtain via DI
RouterFunction<?> route =
route(GET("/hello-world"), handler::helloWorld)
.and(route(GET("/the-answer"), handler::theAnswer));


RouterFunction<?> route =
route(GET("/hello-world"), handler::helloWorld)
.and(route(GET("/the-answer"), handler::theAnswer))
.filter((request, next) -> {
System.out.println("Before handler invocation: " + request.path());
Response<?> response = next.handle(request);
Object body = response.body();
System.out.println("After handler invocation: " + body);
return response;
});

使用注解的话，类似的功能可以使用 @ControllerAdvice 或者是一个 ServletFilter 来实现。
运行一个服务端
所有这些都很不错，不过仍然有一块欠缺：我们如何实际地将这些函数在一个 HTTP 服务器中跑起来呢? 答案毋庸置疑，那通过调用另外的一个函数。 你可以通过使用 RouterFunctions.toHttpHandler() 来将一个路由器函数转换成 HttpHandler
HttpHandler 是 Spring 5.0 M1 中引入的一个响应式抽象: 它能让你运行许多的响应式运行时: Reactor Netty, RxNetty,
Servlet 3.1+, 以及 Undertow。在本示例中，我们已经展示了在 Reactor Netty 中运行一个路由会是什么样子的。对于
Tomcat 来说则是像下面这个样子：
需要注意的意见事情就是上面的东西并不依赖于一个 Spring 应用程序上下文。就跟 JdbcTemplate 以及其它 Spring 的工具那样, 要不要使用应用程序上下文是可以选的: 你可以将你的处理器和路由器函数在一个上下文中进行绑定，但并不是必须的还要注意的就是你也可以将一个路由器函数转换到一个 HandlerMapping中去，那样就它可以在一个 DispatcherHandler 能是跟响应式的 @Controllers 并行)中运行了。
结论
至此便结束了对 Spring 新功能性 web 框架的介绍。让我简单小结一下：
处理功能通过作出回应来处理请求，
路由器功能可连接到处理功能，并可与其他路由器功能共用，
路由器功能可由过滤器的功能进行过滤，
路由器功能可在响应式网络运行机制中运行。