How does this project differ from CPPREST?

[David-Haim-zz]

It appears like this project overlaps the http_client class in CPPREST. What is the difference between this project and CPPREST?

[jasonsandlin]

Yes it is similar. Here's the key differences:

• libHttpClient is brand new and not ready to use, while cpprestsdk is very mature and well tested.
• libHttpClient is a flat C API while cpprestsdk is a C++ API
• libHttpClient supports simple P/Invoke without needing to use the "C#/.NET P/Invoke Interop SDK" https://en.wikipedia.org/wiki/Platform_Invocation_Services#C.23.2F.NET_P.2FInvoke_Interop_SDK
• libHttpClient to lets call control the memory allocations via callback API (similar to XDK's XMemAlloc)
• libHttpClient has no dependencies on PPL or Boost
• libHttpClient has API to let caller manage internal threads
• libHttpClient has API to let caller can add support for other platforms via callback API with a sample showing off an HTTP implementation via Curl https://github.com/curl/curl via this callback
• libHttpClient has no support for streams
• libHttpClient has built-in retry support according to Xbox Live best practices (obey Retry-After header, jitter wait, etc) according to https://developer.microsoft.com/en-us/games/xbox/docs/xboxlive/using-xbox-live/best-practices/best-practices-for-calling-xbox-live
• libHttpClient has built-in Xbox Live throttle handling logic
• libHttpClient has built-in API support to switch to mock layer

[David-Haim-zz]

OK, I still don't quit understand as for why this project came to being. what kind of problems it tries to solve that CPPREST/.NET/Custom Winhttp wrapper can't solve? what are the underlying goals of this project?

[jasonsandlin]

Its trying to address some requests by Xbox game developers that use Xbox Live APIs found here: https://github.com/Microsoft/xbox-live-api. This Xbox Live project currently wraps the CppRestSDK and does some of the above in wrappers, but these issues can't be solved by wrappers around CppRestSDK:

• Memory allocations routed to game's memory manager
• Game is in full control of internal threads (number of active threads and which core they run on)
• No dependencies on PPL or Boost to avoid large libraries and template bloat by using pplx::task which causes lib to get bigger with each new T.
• Uses native platform HTTP/Websocket APIs on iOS/Android instead of Boost