# Choosing a HTTP Client Library **URL:** \ **Category:** Learning\ **Created:** [June 15, 2021, 12:24am UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998 "2021-06-15T00:24:16Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![lambda\_foo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/lambda_foo/32/275_2.png) [@lambda\_foo](https://discuss.ocaml.org/u/lambda_foo)\ **Post date:** [June 15, 2021, 12:24am UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/1 "2021-06-15T00:24:17Z")
What is the advice on writing a new library that needs to make HTTP requests? Should I be using old reliable [cohttp](https://github.com/mirage/ocaml-cohttp) which I already know or something newer like [httpaf](https://github.com/inhabitedtype/httpaf)? Other options I’m not aware of? There are no extreme speed requirements, which httpaf looks to promise. I do need lwt/async support and the possibility of working with Javascript later on, which is available in either option. Thanks in advance for the advice. ---
**Author:** ![yawaramin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yawaramin/32/3384_2.png) [@yawaramin](https://discuss.ocaml.org/u/yawaramin)\ **Post date:** [June 15, 2021, 1:53pm UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/2 "2021-06-15T13:53:21Z")
A couple of others: - Straightforward curl bindings: [http://opam.ocaml.org/packages/ocurl](http://opam.ocaml.org/packages/ocurl) - Pure OCaml client implementation: [http://opam.ocaml.org/packages/piaf](http://opam.ocaml.org/packages/piaf) The latter can probably be run on JSOO, but I’m not 100% sure. May depend on TLS bindings. ---
**Author:** ![anmonteiro](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/anmonteiro/32/300_2.png) [@anmonteiro](https://discuss.ocaml.org/u/anmonteiro)\ **Post date:** [June 15, 2021, 6:35pm UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/3 "2021-06-15T18:35:31Z")
I doubt Piaf works with JSOO, as it has a hard dependency on `ocaml-ssl` and OpenSSL. ---
**Author:** ![tungd](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/tungd/32/2740_2.png) [@tungd](https://discuss.ocaml.org/u/tungd)\ **Post date:** [June 16, 2021, 4:38am UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/4 "2021-06-16T04:38:01Z")
Personally, I still prefer Cohttp for the client side, to me it is better documented and the API is more straightforward to use compared to Httpaf. AFAIK Httpaf was created to address the issues with the Cohttp server, not the client. Not to mention that Cohttp also support JSOO. ---
**Author:** ![lambda\_foo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/lambda_foo/32/275_2.png) [@lambda\_foo](https://discuss.ocaml.org/u/lambda_foo)\ **Post date:** [June 16, 2021, 4:45am UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/5 "2021-06-16T04:45:51Z")
> [@tungd](#): > > AFAIK Httpaf was created to address the issues with the Cohttp server That is implied in the benchmarks I suppose. Cohttp seems like the right option, with `piaf` looking quite interesting as the next thing to checkout. What was the motivation for doing HTTP/2 in `piaf` over hacking it into `cohttp`? @anmonteiro ---
**Author:** ![roddy](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/roddy/32/2261_2.png) [@roddy](https://discuss.ocaml.org/u/roddy)\ **Post date:** [June 16, 2021, 11:04pm UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/6 "2021-06-16T23:04:54Z")
I wrote a wrapper ([quests](https://github.com/roddyyaga/quests)) around cohttp which I think has a significantly nicer API. It doesn’t have JSOO support at the moment; if Cohttp\_lwt\_jsoo can easily replace Cohttp\_lwt\_unix it would be easy to add. ---
**Author:** ![anmonteiro](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/anmonteiro/32/300_2.png) [@anmonteiro](https://discuss.ocaml.org/u/anmonteiro)\ **Post date:** [June 16, 2021, 11:39pm UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/7 "2021-06-16T23:39:51Z")
HTTP/2 is a significantly different protocol than HTTP/1, and that was the rationale for a new repo. It’s also built on the same architecture as http/af and meant to be used together, such as the Piaf use case. Note, however, than Piaf uses my [fork](https://github.com/anmonteiro/httpaf) of http/af, which among other things adds persistent connections and pipelining to the client. ---
**Author:** ![mefyl](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/mefyl/32/2970_2.png) [@mefyl](https://discuss.ocaml.org/u/mefyl)\ **Post date:** [June 18, 2021, 9:03am UTC](https://discuss.ocaml.org/t/choosing-a-http-client-library/7998/8 "2021-06-18T09:03:00Z")
It should be a simple matter of wrapping everything in a functor over `Cohttp_lwt.S.Client`. It’s very likely you don’t use anything specific to Unix and it will work out of the box.