Boost xxhr ? High level http client library
Dear Boost, I've built an header-only library based on Boost.Beast which allows you to perform HTTP requests. It is implememented with two backends : * Boost.Beast for native builds. * XmlHttpRequest for WebAssembly (plans to migrate to fetch API which is richer) Actually Boost.Beast is a great lib, however it's API is thought to build HTTP centric app not just to make some simple HTTP call ( as for example urdl was ). xxhr on the other hand is about making it simple to call an HTTP service. Usage example : GET <https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de863f52b97cb>( "http://httpbin.org/anything"s, on_response = [](auto&& resp) { std::cout << resp.text; }); I would be really interested in a pre-review or some feedback about it's API. The implementation merits more attention and can significantly be improved but this email is to grab a first feedback from the community. Documentation : https://nxxm.github.io/xxhr/ GitHub : https://github.com/nxxm/xxhr Example code relying on it : nxxm/gh <https://github.com/nxxm/gh>: partial GitHub API implementation Thanks for your time :) -- Damien Buhl Software Developer +33 6 77 43 10 05 https://nxxm.github.io/
2018-09-28 5:58 GMT-03:00 Damien Buhl via Boost <boost@lists.boost.org>:
GET <https://nxxm.github.io/xxhr/html/namespacexxhr.html# a69bafa24d7c33b004a7de863f52b97cb>( "http://httpbin.org/anything"s, on_response = [](auto&& resp) { std::cout << resp.text; });
Use ASIO async model. Completion token as last argument. N4045[1] is a good read to get you started. I can help review the library once you finish this small task. [1] https://isocpp.org/files/papers/n4045.pdf -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
On 28/09/2018 05:32, Vinícius dos Santos Oliveira wrote:
2018-09-28 5:58 GMT-03:00 Damien Buhl via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>>:
GET <https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de86... <https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de863f52b97cb>>( "http://httpbin.org/anything"s, on_response = [](auto&& resp) { std::cout << resp.text; });
Use ASIO async model. Completion token as last argument. N4045[1] is a good read to get you started.
I can help review the library once you finish this small task.
Nice catch and Thanks Vinícius for pointing that out. I've considered bringing that at the top-level of the API as one is used to with Asio, but the reason I didn't do it for now is that it requires me alot more of implementation (that I'd like to make) for the WebAssembly backend which hasn't asio. One important point for me is that this high-level API forces an asynchronous way of thinking your programs, because it is the only way to have C++ that returns CPU time to environments like a Web browser WASM implementation.
I can help review the library once you finish this small task. Cool I would enjoy it, I'll ping you back when I've integrated a completion token in the API.
-- Damien Buhl Software Developer +33 6 77 43 10 05
On Fri, Sep 28, 2018 at 1:59 AM Damien Buhl via Boost <boost@lists.boost.org> wrote:
I would be really interested in a pre-review or some feedback
I had a look and I this your library would benefit from a strong separation of concerns. For example the Beast "session backend" has code related to multi-part encodings. In my opinion this would be more useful if it was a separate, well-defined interface that had nothing to do with Beast or Asio. The same principle applies to other code in the implementation, such as following redirects. Designing code to handle redirects as a set of free functions which operate on `beast::http::response` objects would be generally helpful, and as an added bonus would allow you to more easily write unit tests. Overall this library looks like it is off to a promising start! Regards
On 29/09/2018 21:11, Vinnie Falco via Boost wrote:
I would be really interested in a pre-review or some feedback I had a look and I this your library would benefit from a strong separation of concerns. For example the Beast "session backend" has code related to multi-part encodings. In my opinion this would be more useful if it was a separate, well-defined interface that had nothing to do with Beast or Asio. The same principle applies to other code in
On Fri, Sep 28, 2018 at 1:59 AM Damien Buhl via Boost <boost@lists.boost.org> wrote: the implementation, such as following redirects. Designing code to handle redirects as a set of free functions which operate on `beast::http::response` objects would be generally helpful, and as an added bonus would allow you to more easily write unit tests.
Overall this library looks like it is off to a promising start!
Regards
Thanks for this first review, indeed refactoring the session backend and extracting the bits that are too specific would make sense. Is there in Beast a way to do the multipart encoding ? Or would it be of interest if I first factor it out and implement it in a more robust way so that it may enter once Beast ? Or is multipart something you don't see in Beast ? Cheers
On Fri, Oct 12, 2018 at 2:10 AM Damien Buhl via Boost <boost@lists.boost.org> wrote:
Is there in Beast a way to do the multipart encoding ? Or would it be of interest if I first factor it out and implement it in a more robust way so that it may enter once Beast ? Or is multipart something you don't see in Beast ?
Encodings for the body (other than the chunked transfer-encoding) are, as they say, "out-of-scope" for Beast! Regards
participants (3)
-
Damien Buhl -
Vinnie Falco -
Vinícius dos Santos Oliveira