This post will be to simply show a contrasting api defined using a Java based fluent api and a Kotlin based DSL
A functional way to define a CRUD based Spring Webflux endpoint in Java would look like this:
RouterFunction<?> apis() { return nest(path("/hotels"), nest(accept(MediaType.APPLICATION_JSON), route( GET("/"), messageHandler::getMessages) .andRoute(POST("/"), messageHandler::addMessage) .andRoute(GET("/{id}"), messageHandler::getMessage) .andRoute(PUT("/{id}"), messageHandler::updateMessage) .andRoute(DELETE("/{id}"), messageHandler::deleteMessage) )); }
The details of the endpoint is very clear and is defined in a fluent manner with just a few keywords - route, nest and the HTTP verbs.
These endpoints can be expressed using a Kotlin based DSL(and some clever use of Kotlin extension functions) the following way:
@Bean fun apis() = router { (accept(APPLICATION_JSON) and "/messages").nest { GET("/", messageHandler::getMessages) POST("/", messageHandler::addMessage) GET("/{id}", messageHandler::getMessage) PUT("/{id}", messageHandler::updateMessage) DELETE("/{id}", messageHandler::deleteMessage) } }
I feels that this reads a little better than the Java based DSL. If the API is more complicated, as demonstrated in the excellent samples by Sébastien Deleuze with multiple levels of nesting, the Kotlin based DSL really starts to shine.
In the next post, I will delve into how this support has been implemented.
This sample is available in my github repo here
No comments:
Post a Comment