Support pluggable HTTP client

[greglook]

In its initial incarnation, vault-clj used the clj-http client, which is built on Apache's http client. Later, for compatibility with babashka (and graal) this switched to http-kit, which is much lighter-weight. Some consumers may still want a simpler approach and fewer dependencies, and Java 11+ comes with a new built-in HttpClient class. Ideally, we could structure the client so that users could select among several HTTP clients, or even implement their own.

The main thing necessary to fit into the current control flow logic is for the client to be able to operate asynchronously and invoke on-success or on-error callbacks, similar to how http-kit works.

[greglook]

Still an interesting idea, but not going to block 2.x on this.

[jasonjckn]

fyi, i have to fork & remove httpkit because it had an obscure bug , we're on hato http client / jdk11 now :)

Less important but not without merit, is jsonista performs much better than data.json, from what I understand.

Off the top of my head, I can't remember how pervasive data.json is in the code base, but if its only ever used for HTTP response parsing, you could put both HTTP Client & JSON lib, into the the same abstraction.

The interface could be ~ http/request with an as implicit :as json that's implementation dependent, and/or use multimethods to allow extensible :as (maybe related to https://github.com/amperity/vault-clj/issues/100)

--

do you have any preferred approach to supporting optional library dependencies?

If you still want to dynamically refer to hato/clj-http/httpkit in the code, i've seen approaches that use requiring-resolve, eval, Class/forName,

Or you can just not refer to any particular library in the code, e.g. multimethods, protocols, slf4j-api style, polylith-style, etc.