Simple, modern HTTP client library?

Ecosystem
14

Thanks for the detailed explanation, let me try to summarize the various choices in this table, please let me know if I missed any or got it wrong:

name OCaml dependencies System dependencies OCaml 5.0 support HTTP 1.x HTTP /2 OpenSSL Ocaml-TLS Unikernel support
ezcurl 5 1 :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :x: :x:
hyper 44 2 :x: :white_check_mark: :white_check_mark: :white_check_mark: :x: :x:
piaf 50 2 :x: :white_check_mark: :white_check_mark: :white_check_mark: :x: :x:
cohttp-lwt 74 3 :white_check_mark: :white_check_mark: :x: :white_check_mark: :white_check_mark: :white_check_mark:
paf 81 3 :white_check_mark: :white_check_mark: :white_check_mark: :x: :white_check_mark: :white_check_mark:
http-lwt-client 92 3 :white_check_mark: :white_check_mark: :white_check_mark: :x: :white_check_mark: :white_check_mark:

dependencies were counted by installing into a fresh switch on 5.0 where possible, if not then 4.14.1, running opam list and subtracting 11 , the number of base packages in a vanilla switch, and also opam list --depexts on Fedora 37. The checkmarks are based on project descriptions, dependencies and this thread, I haven’t actually tested whether each feature works. I didn’t list http/af and h2 in the table because they seem to be low-level libraries that are not meant to be used directly.
http-lwt-client is considered to “support” mirage through “mirage-lwt-client”.
‘ezcurl’ is considered to support OpenSSL on some OSes (it may also use GnuTLS or NSS).
I didn’t list HTTP/3, because only ‘curl’ would support that, but even there the support is experimental

None of the libraries “tick all the boxes”, so there is a paradox of choice here (still the original ‘cohttp’ comes closest to ticking them all, if it wasn’t for the lack of HTTP/2 support)

I don’t think it is unreasonable to expect a small dependency cone for http-lwt-client when its README claims it as a feature, however according to the above table its dependency cone is the largest.
If a small dependency cone is not a goal of the project, that is fine, however advertising it in the README sets an expectation for users (to be fair though, its direct dependency list is smallish).

To answer the question about level: we are currently using a combination of ‘cohttp’ applied with a custom ‘Unix’ functor, and ‘cohttp-lwt-unix’ + ‘lwt_ssl’. However this is limited to HTTP/1.x and we thought to investigate and try something new, with the eventual goal of perhaps using gRPC.
It is not very clear what conduit’s “successor” is (or whether it needs one):

  • tuyau (which apparently got merged into conduit?)
  • gluten
  • mimic

IIUC then mimic is the preferred choice nowadays?

Thanks for the mention of piaf btw, I was aware of paf but haven’t noticed the existence of piaf due to its similarity in name (and that it is a completely different project)

There are of course lots of other criterias for choosing an http library, most importantly “does it work”, do the examples from its documentation work, and maturity level of the library and we haven’t tried them all yet. And although ezcurl seems like a nice choice in terms of dependencies, and API simplicity, it failed to send an HTTP POST with JSON contents (PR opened, seemed easy enough to fix!).

I’m also aware of the ocaml-grpc library, however it might be a bit too early to try it out, it doesn’t seem to have any TLS support at all yet (although that functionality could perhaps be built on top of it).

4 Likes