I was able to set up Rest API with my basic auth on api/** path. Which is different than normal Vaadin /connect api.
I annotated my @BrowserCallable class methods with @PostMapping and @RequestBody on params to expose them to /api/** routes.
All the calls work when normally called from within the Vaadin app. But if I use same parameters on api/** methods they do not work.
Now, I am facing issues where the API calls do not work because there are no mappers defined for the Deserializing Objects used in Hilla like Filter, OrFilter, AndFilter or Pageable.
Is it possible to use the same method that is used by hillla to work with @BrowserCallable?
Why do you want to expose the same service methods in multiple ways? I’m just trying to understand the requirements here since the typical case is that different clients have different data needs and thus also separate methods.
Hilla uses an internal ObjectMapper with special handling for types such as Filter and Pageable that you mention. I would not recommend reusing that mapper for other purposes since the JSON format might be changed at any time without considering that as a breaking change. That’s typically not what you want to have for REST endpoints used by external clients.
I would thus recommend that you define separate service methods for the Hilla frontend and for REST clients since they have different needs for how e.g. API evolution is managed. They can still be part of the same code base and reuse the same underlying services.
My use case is exacly same, have rest endpoints for external clients. I was thinking since @BrowserCallable are already separate controller classes calling service layer, I will use same without creating more endpoints and exposing few of the @BrowserCallable to external api as needed.
I agree, it might have adverse effect, if anything change there, external api will also be affected.
I will try with creating separate external endpoints using same service layer.