I have used How to implement client middleware in Hilla | Vaadin to create some custom headers. These are metadata fields which are cross cutting and do not belong to the response body.
How do i access HTTP Headers on the Java endpoint side?
Tried Spring MVC way (@RequestHeader) in endpoint code does not work.
What are you trying to achieve exactly?
I am passing metadata like pagination details, data version etc information in the requestt headers and need it back in response. I will than have business logic around this.
And what’s the reason you’re not passing this information in the request body? Typically, you’d only pass things like authorization or authentication related information in the headers. Whatever the metadata, it’s usually meant to be processed by intermediary things like servlet filters, not the endpoint.
1 Like
So that the framework takes care of repetitive things and do not pollute the DTO/FDO.
I do understand the other design as well that you mentioned . I was also not able to locate how do i get request parameters in the URL as well. Lets just say the middleware in hilla will take care of decorations and developer just implement the logic and not having to worry about handling the implementation.
Found this in doc, How to use query parameters in a Vaadin application but could not find how to pass query params to the backend endpoint
I would’t recommend using HTTP headers for things like paging data that aren’t relevant for all endpoint calls. You want to have it explicitly documented in the signature of each method whether it expects to receive that kind of data or not.
With that said, you can access anything related to the current request through the ServletRequestAttributes class in Spring.
It sounds to me like you’re maybe thinking of Endpoints too much on the implementation detail level. You’re focusing on things like HTTP requests and URLs (like you would in Spring MVC), but I think the design intent is more about the framework providing abstract browser-callable services with an automatically generated client. The framework happens to use HTTP requests under the hood, but they might also be Websockets requests or something completely different.
One specific thing that we have envisioned but not implemented is request aggregation. The idea would be that if you do multiple endpoint calls during the same microtask, then they would all be combined into a single HTTP request. On the other hand, HTTP/2 will anyways eat up 90% of the overhead you would get from multiple smaller request so it might not be worth it in the end. But that’s at least an example of the possibilities you get from viewing Hilla endpoint method calls as method calls rather than as HTTP requests.