What is the advice on writing a new library that needs to make HTTP requests?
Should I be using old reliable cohttp which I already know or something newer like 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.
A couple of others:
The latter can probably be run on JSOO, but I’m not 100% sure. May depend on TLS bindings.
I doubt Piaf works with JSOO, as it has a hard dependency on ocaml-ssl and OpenSSL.
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.
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
I wrote a wrapper (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.
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 of http/af, which among other things adds persistent connections and pipelining to the client.
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.