# Simple, modern HTTP client library?

**URL:** <https://discuss.ocaml.org/t/simple-modern-http-client-library/11239>\
**Category:** Ecosystem\
**Created:** [January 24, 2023, 1:28pm UTC](https://discuss.ocaml.org/t/simple-modern-http-client-library/11239 "2023-01-24T13:28:04Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![edwin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/edwin/32/627_2.png) [@edwin](https://discuss.ocaml.org/u/edwin)\
**Post date:** [February 2, 2023, 12:04am UTC](https://discuss.ocaml.org/t/simple-modern-http-client-library/11239/14 "2023-02-02T00:04:27Z")

</div>

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 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
| hyper | 44 | 2 | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ |
| piaf | 50 | 2 | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ |
| cohttp-lwt | 74 | 3 | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ |
| paf | 81 | 3 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| http-lwt-client | 92 | 3 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |

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).

---

_[View the full topic](https://discuss.ocaml.org/t/simple-modern-http-client-library/11239)._