How to write a REST client library that is framework agnostic

[jmini]

I could not found much information on this topic, but I have the feeling this is a quite common problem.

As an author of a REST client library, the work is all about providing models (java classes with Jackson annotation) that represents Request Body and Response Body and providing methods to call the different endpoint. So that the user do not have to write the HTTP request. He just call apiClient.getAll<EntityName>() or apiClient.create<EntityName>(Entity instance)...

One project I am contributing to GitLab java client, make me think about those.

At the end my feeling is that this library could be totally agnostic from the layer that really performs the HTTP calls.

For example the GitLab client mentioned earlier has Jersey to do this as a dependency.
This is no problem to integrate with Quarkus (as long as you take the correct Jersey version to be compatible with jakara or javax package name for the JAX-RS stuff).
I have the feeling this is too much, since this means that Quarkus App using the GitLab client will suddenly import Jersey instead of the preferred Quarkus approach (which I think is RESTEasy-client. reactive flavour or not).

Also when compiling to native (I never tried that) seem to require additional configuration #1647 (comment)

I am wondering what is the recommendation for a case like that:

• Maybe ideally have a layer that is HTTP client agnostic
• And then provide bindings for the different tech stack out there:
  • built in Java client (available since java 11)
  • OkHTTP which seems to be popular in the Kotlin space
  • RESTEasy when using with Quarkus
  • Something else when using with Spring
  • ...

I do not find any approach like this. I also have the feeling there is no API to describe HTTP calls without an actual implementation, letting people bring the implementation they would like, depending on the App Server stack they are using.

I would appreciate getting feedback from the Quarkus community where optimizing the size and number of dependency matters.

[jmini]

See this answer: #36024 (comment)

[codespearhead]

@jmini Should this discussion be closed then?