Annotation for notifications (nrich-notification)

[nkescec]

Idea

The idea consists of annotations for route methods that specify what kind of notification should be automatically added in the response.

It would improve nrich-notifcation so that the user doesn't need to include NotificationResponseService in the controller class and return a notification instance. Instead, user could simply annotate the method and then springs route handler would, after handling the request, create required notification and return it in response.

The annotation would be similar to @ResponseBody. It could resolve action codes automatically or would use given action codes that were passed to it as an argument.

Example

As it is now (if we provide action code manually):

    @GetMapping("notification")
    public NotificationDataResponse<String> notificationResponse() {
        return notificationResponseService.responseWithNotification("Hello world!, "notification.notification-with-manual-action-resolving");
    }

With annotation:

    @GetMapping("notification")
    @NotificationWithData("notification.notification-with-manual-action-resolving")
    public String notificationResponse() {
        return "Hello!";
    }

For case that we do not provide an action code:

    @GetMapping("notification")
    public NotificationDataResponse<String> notificationResponse() {
        return notificationResponseService.responseWithNotificationActionResolvedFromRequest("Hello world!");
    }

With annotation:

    @GetMapping("notification")
    @NotificationWithData
    public String notificationResponse() {
        return "Hello!";
    }

[agrancaric]

I was thinking of adding something similar when I was working on this but gave up on the idea eventually. @ResponseBody will keep the original format of response and just do serialisation. With this annotation the format returned will be completely different which won't be obvious by looking at the method. To see the format you would need to go in the annotation javadoc and look at the response format which for me seems a bit unclear. So I am not sure about this, would like to hear other opinions.

[nkescec]

I do not believe that this is such a big problem because this would only happen if somebody annotates that method. That would mean that the user that annotated the method already expects such a response. Or at least, thats what I think. I also welcome opther opinions.

[jzrilic]

At first glance, it seems like too much "magic" for me. In this case, I prefer a few lines more for better code readability. Let's hear what others have to say.

[agrancaric]

Also one more thing came to mind, did you think where would you put this logic? It was quite some time when I last looked at it but I seem to remember that it is not easy to plugin in Spring's default serialisation. you would need to inject your custom handler after getting the result from the controller and before writing it as json/xml/whatever. (ofc I maybe mistaken). Now that I've taken another look maybe it could work with a ResponseBodyAdvice, although not sure can you change the return type here, didn't try it.

[nkescec]

Yes, it was exactly ResponseBodyAdvice in my mind as a potential place where this logic could be put. There are two main methods: supports and beforeBodyWrite.

In supports we would check if this return needs to be wrapped into a notification by checking if the returned method is annotated. This would actually change my proposal a bit by annotating the returned method parameter instead of the method itself.

In beforeBodyWrite, that we would parametrize by Object, we could check the returned value's annotation and create required notification.

There are a few things that I am unsure about. I don't believe that this solution would work for methods that return nothing. Also, I am not sure whether Spring would serialize the returned object correctly because I don't know if he already decides what serializer to use before the invocation of beforeBodyWrite.
In short, I would try to check some of these things out.