Deprecated dependency: cpprestsdk is now in maintenance mode

[connorfeeley]

As of March 8th, cpprestsdk is in maintenance mode.

From the README: cpprestsdk is in maintenance mode and we do not recommend its use in new projects. We will continue to fix critical bugs and address security issues.

There are currently about 700 open issues, and the last commit was on March 11th.

Given that the project appears essentially abandoned (and is unlikely to receive fixes for new compilers or boost releases), are there any plans to migrate to a different REST library?

This currently doesn't seem to be a pressing issue, but in the longer term the cpprestsdk dependency may cause compatibility problems.

[garethsb]

That's a good question. Personally (and definitely not speaking for the current team at Sony), I think investigating options here is a good idea. At the point that cpprestsdk was selected, it provided the best balance of features and platform and compiler support. Other potential libraries were more bloated or immature. That has changed. However, there are obviously parts of the nmos-cpp design that are currently tied to the way that cpprestsdk provides these features.

I agree that in the short term, there are few concerns, nmos-cpp is fairly stable and both it and cpprestsdk have weathered a series of evolutions of platform and compiler already. There are no obvious missing infrastructure features required for current or near term NMOS enhancements. The cpprestsdk codebase could be maintained fit for this project's purpose for sometime.

That said, open-source C++ cross platform networking libraries like Boost.Beast have matured in the last couple of years, and with json support provided by e.g. nlohmann/json or Boost.JSON, and several options for async task management to replace pplx, nmos-cpp could be transitioned, especially if the minimum C++ standard requirement were updated past GCC 4.8—era C++11.

This issue could be a good place to identify the options between those extremes.

[garethsb]

I thought I'd make a start on a list of features to look for when evaluating alternative libraries, besides the obvious ones of OSS licence, level of project maintenance/activity, cross platform, C++ language version/compiler support (CI tests!), sufficient performance, Conan/vcpkg support, and recursively for additional dependencies...

Network I/O Features

Used by nmos-cpp now:

• HTTP/1.1 client
• HTTP/1.1 server
• WebSocket client
• WebSocket server (one of nmos-cpp's cpprest extensions)
• Secure comms (TLS 1.2 and 1.3) for all of above
• Async connection processing on server side
• Connection pooling on client side
• Socket options
• Express style routing (one of nmos-cpp's cpprest extensions)

Nice to have (things cpprestsdk doesn't provide):

• HTTP pipelining (server- and client-side)
• HTTP to WebSocket upgrade
• Binding to specific multiple interfaces

Potentially useful in the future:

• HTTP/2, etc.

JSON Features

Used by nmos-cpp now:

• JSON serialization and deserialization from/to 'DOM' and via events (an nmos-cpp extension to cpprest)
• JSON syntactic validation
• JSON merge patch (ish, another extension)
• JSON Schema (draft-04) validation (another extension)
• JSON 'DOM' construction from C++ nested braced initializer list (yep, another extension)

Nice to have:

• JSON Schema draft-07 (and newer, it inches closer to RFC!)

[connorfeeley]

I'm fully in agreement with all you've said (and I'm certainly under no impressions that swapping out the library would be trivial!). As you said - I think this issue would be a good place to discuss options.

REST Libraries

I'm currently in the process of building a REST server for one of our products and I did some investigation into available libraries (which was when I learned that cpprestsdk is in maintenance mode) so I have some fairly barebones notes about some of the options.

I looked at Pistache, Restbed, and Boost.Beast - though I'm sure there are other viable alternatives.

Pistache:

• C++17
• HTTPs support
• No boost dependency
• Basic "hello world" example is 32KiB
• Not version 1.0 yet

Pistache felt fairly ergonomic to use, but the documentation was rather sparse. The project's immaturity worried me a bit.

Restbed:

• AGPL or proprietary license

I pretty much stopped investigating Restbed after I saw the licensing. Apart from that, I got the impression it was fairly high-quality.

• Boost.Beast:
  • C++11 with Boost, but can be used standalone with C++17
  • Introduced in Boost 1.66
  • HTTP/1.1 client/server
  • (Secure) websocket client/server
  • TLS 1.1, 1.2, 1.3 client/server
  • Async client/server
  • No connection pooling built-in
  • No build-in routing
  • HTTP to websocket upgrade

I eventually settled on Boost.Beast. It's very low level (no built-in routing, for example) and it's also my first foray into Boost so it's been a fairly steep learning curve for me. But given that it's a part of Boost, I don't really have any concerns about quality or maintenance. It ticked all the boxes I needed, and it looks like it almost satisfies all of the criteria you laid out - except for routing and connection pooling - though I believe you can accomplish pooling with Boost.ASIO, but I think you'd have to roll your own router.

JSON Libraries

I'm also using nlohmann JSON on the same project; so far I'm fairly happy with it, although there are some more modern C++ features that I'd have liked to see in it (random example: no built-in support for std::optional, but you can work around that). If I recall correctly the library targets C++11, so the std::optional annoyance is understandable.

I've used JsonCPP in the past and I'm not a big fan of it - without diving into details, I found it encourages difficult-to-maintain code.

Of the other JSON libraries I can name off the top of my head:

• RapidJSON: I've never used it, so I can't really comment on it.
• Boost.JSON: I've also never used it, but it seems to be only available in Boost >=1.75, which might be a bit too recent for a project like this where some of the users may be tied to ancient vendor-supplied toolchains.

[VenkateswaranJ]

https://github.com/yhirose/cpp-httplib

[garethsb]

https://github.com/dfleury2/beauty

[garethsb]

We've heard a request to use OpenSSL 3.0 rather than OpenSSL 1.1 as well, since the latter will be end-of-life in September 2023 - https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/.

Boost.ASIO supports OpenSSL 3.0 since 1.79.0 (see release notes)

We hope there are no additional direct dependencies on OpenSSL APIs from WebSocket++ (websocketpp) or C++ REST SDK (cpprestsdk)...