is there a good way to avoid the repetition below while dealing with missing property keys at the same time?

https://huynt.wordpress.com/2012/08/09/jsr-303-bean-validation-nested-validation/ So, to validated nested properties I need to put

@Valid

to these properties, is it possible somehow to configure Spring to do this by default for every nested property?

What do you think about providing both

ServerRequest.awaitBody

and

ServerRequest.awaitBodyOrNull

https://github.com/spring-projects/spring-fu/issues/197 ?

Currently I only provide the nullable one

But it is commonly used so it maybe deserve providing the 2 variants

I think I need also to change

ServerRequest.awaitPrincipal(): Principal

to

ServerRequest.awaitPrincipal(): Principal?

(I think the usual pattern is to use

OrNull

only if there is multiple variants to differentiate)

I probably need to do the same for

ClientResponse.awaitBody()

->

ClientResponse.awaitBody()

and

ClientResponse.awaitBodyOrNull()

I think it feels natural to have awaitBody + awaitBodyOrNull

Another question, on

WebClient

I have made an exception to the pattern I use (

await

prefix or

AndAwait

suffix), I have translated

fun exchange(): Mono<ClientResponse>

to

suspend fun awaitResponse(): ClientResponse

instead of

suspend fun exchangeAndAwait(): ClientResponse

. Any thoughts?

It is very common and I found

exchangeAndAwait

not very nice, so I chose

awaitResponse

for now

It may surprise people knowing the Java API the first time

But I tend to see

suspend fun awaitResponse(): ClientResponse

more idiomatic

Any feedback welcome.

I would absolutely favor

await...

. But translating exchange to

awaitResponse

feels odd - why not

awaitExchange

?

The pattern

fun awaitSomething()

is usually used when the return type is

Something

, when there is an operation that returns another type I use

AndAwait

suffix to avoid confusion.

For example see with body

awaitBody

returns the body asychronously

Here we want to perform the exchange and wait the response

Hence my alternative proposal of

exchangeAndAwait

Which is consistent with all I did in other places

I came to that pattern via

ServerResponse.BodyBuilder.bodyAndAwait

Where we set the body then await

For exchange I felt it was a similar pattern

Maybe I am wrong not sure

For

ServerResponse.BodyBuilder.bodyAndAwait

I am 100% sure

awaitBody

is wrong since we set the body then await

For translating

fun exchange(): Mono<ClientResponse>

this is less clear

Maybe

awaitExchange

could be fine after all

That would mean a

suspend fun awaitExchange(): ClientReponse

API