Java SDK: Choosing an HTTP client library
booniepepper opened this issue · 3 comments
Let's get the best HTTP client library that will fit OpenFGA needs:
The primary list I'm considering is the list of library options from openapi-generator:
https://github.com/OpenAPITools/openapi-generator/blob/master/docs/generators/java.md#config-options
Features
| Library | JDK | Abstraction | NIO (Non-blocking IO) | HTTP2 |
|---|---|---|---|---|
| Apache HttpClient (5) | 7+ | HTTP | Yes | Yes |
| Java 11 HttpClient | 9+ | HTTP | Yes | Yes |
| Jersey 3 | 7+ | REST | Yes | Yes* ( *requires Jetty) |
| OkHttp | 8+ | HTTP | No | Yes |
| OpenFeign | 8+ | HTTP | No | Yes* (* requires JDK 11+) |
| Resteasy | 8+ | REST | No | No |
| Vert.x | 8+ | HTTP | Yes | Yes |
All above support both synchronous and asynchronous execution. They also all support HTTP Header
customization, although the REST versions tend to have more abstraction.
The following HTTP libraries are supported by the Open API generator, but are
not stand-alone projects, so are not included in the table above:
- Google API client, Spring RestTemplate, Spring WebTemplate. These are frontends that allow for pluggable HTTP backends (like Apache HTTP, or Java 11's HttpClient)
- rest-assured is a REST wrapper over Apache HttpClient
- Microprofile is a REST wrapper over another REST library
Feature References:
- Links above, per project
- https://reflectoring.io/comparison-of-java-http-clients/
Benchmarking
Benchmarking References:
- https://dzone.com/articles/high-concurrency-http-clients-on-the-jvm
- https://www.techempower.com/benchmarks/#section=data-r21&hw=ph&test=update&p=zik0zj-qmx0qn-zik0zj-zijzb3-4fti4f&a=2
Notes: The long-term support (LTS) versions of JDK today are 8, 11, 17. JDK 8 ended active
support in May 2022, but is widely used and will see security support until 2030. JDK 21 is
scheduled for release in Sept 2023.
Thanks @booniepepper! May I ask you to add a column for HTTP2 support? And native HTTP Client in Java 11+?
If the native client works it would make a lot of things easier. We went that route in the Go and .NET SDKs for the sake of dropping extra production dependencies
There's a column for HTTP2 support already. the "native" client is the row called "Java 11 HttpClient" (Technically it's available from JDK 9 as an incubator feature)
Let's go with the HttpClient w/ Java 11+ for now.
Not a lot of enterprises w/ legacy code will be adopting FGA in their code as is, usually they make a separate service and integrate with that.
The folks in Discord and that we were talking to have not mentioned Java 8 support.
Going with the built in client allows us to have 1 less dependency we need to worry about.
In case anyone needs it in the future we can provide instructions on how to generate an SDK that works for them