Microsoft C++ REST SDK Is Archived: What to Use Instead

Microsoft archived the C++ REST SDK repository on 1 June 2026. It is read-only, 797 open issues and 64 open pull requests are frozen where they stand, and the README now opens with a warning rather than a welcome.

That is not the same as the library being unusable, and the difference matters if you have code depending on it. I installed version 2.10.19 from apt and compiled a client against it with -Wall -Wextra under both GCC 13.3 and Clang 18.1.3. Both built without a single warning and returned HTTP 200. On GCC and Clang, today, it works. On a current MSVC toolset it fails to build outright, according to an upstream report I have not reproduced — and nobody can fix that now. Every program on this page — the SDK itself and all three replacements — was compiled and run for this article on Ubuntu 24.04 with both g++ 13.3 and clang++ 18.1.3, using -std=c++17 -Wall -Wextra, against the same local HTTP server; the examples this refresh replaces described a version that predates the current one by a decade. Every status code, warning count and binary size is captured verbatim.

Is the C++ REST SDK Still Maintained?

Microsoft archived the microsoft/cpprestsdk repository on 1 June 2026, making it read-only. The archived README states that the project “is no longer maintained” and that “no further issues or pull requests will be reviewed”, and it directs users to two alternatives: libcurl and Boost.Beast. The last released version is 2.10.19, which was also the version still shipping in Ubuntu 24.04’s libcpprest-dev package when this was written. The code remains available under its original licence and still ships in vcpkg, apt, dnf, Homebrew and NuGet, so it continues to install and build — but it will receive no further fixes, including security fixes.

That last clause is the one that should drive your decision. A library that still works is a very different proposition from a library that will still work in two years, and the gap between them is exactly the maintenance that just stopped.

What “Archived” Actually Means Here

It is worth being precise, because “deprecated” gets used loosely and the practical consequences differ.

The code has not been withdrawn. It is still on GitHub, still under the same licence, and still packaged. apt-cache policy libcpprest-dev on Ubuntu 24.04 offers 2.10.19-2build2 today, and installing it works normally. A package manager finding it is not evidence that the project is maintained — distributions carry packages long after upstream stops.

It still works where it already worked. Here is a GET against a local server, compiled against the installed 2.10.19:

#include <cpprest/http_client.h>
#include <iostream>

int main() {
    web::http::client::http_client client(U("http://127.0.0.1:8080"));
    client.request(web::http::methods::GET, U("/"))
        .then([](web::http::http_response r) {
            std::cout << "status " << r.status_code() << "\n";
            return r.extract_string();
        })
        .then([](utility::string_t body) {
            std::cout << "bytes  " << body.size() << "\n";
        })
        .wait();
    return 0;
}

Output:

status 200
bytes  529

Zero warnings under -Wall -Wextra. If someone tells you the SDK is broken, that is not true in general — it is true on one important platform, which is the next section.

What has stopped is everything else. No bug fixes, no security patches, no support for new compiler releases, no answers to the 797 issues. The library is frozen at the state of the C++ and toolchain ecosystem as it was, and both of those keep moving.

The MSVC Problem

The clearest illustration of what freezing costs: the SDK’s headers use stdext::checked_array_iterator, which Microsoft’s own standard library has since removed. On current MSVC toolsets the build fails outright:

containerstream.h(404,39): error C2653: 'stdext': is not a class or namespace name

That was reported in March 2026, three months before the archive. I have not reproduced this — there is no Windows machine behind this article, so the error text and its cause come from the upstream report rather than from my own build.

This is the shape of the risk in general. The failure will not be dramatic; it will be a toolchain upgrade that suddenly does not build, at a time you did not choose, with no upstream to escalate to. If you are on MSVC, that time has already arrived.

Your Migration Options

Microsoft’s archived README names two replacements. I have added a third that is worth knowing about, and compiled all of them.

libcurl — the most widely ported, and the smallest here

#include <curl/curl.h>
#include <iostream>
#include <string>

static size_t sink(char *p, size_t sz, size_t n, void *ud) {
    static_cast<std::string *>(ud)->append(p, sz * n);
    return sz * n;
}

int main() {
    curl_global_init(CURL_GLOBAL_DEFAULT);
    CURL *c = curl_easy_init();
    std::string body;

    curl_easy_setopt(c, CURLOPT_URL, "http://127.0.0.1:8080/");
    curl_easy_setopt(c, CURLOPT_WRITEFUNCTION, sink);
    curl_easy_setopt(c, CURLOPT_WRITEDATA, &body);

    CURLcode rc = curl_easy_perform(c);
    long status = 0;
    curl_easy_getinfo(c, CURLINFO_RESPONSE_CODE, &status);

    if (rc == CURLE_OK) {
        std::cout << "status " << status << "\n";
        std::cout << "bytes  " << body.size() << "\n";
    }
    curl_easy_cleanup(c);
    curl_global_cleanup();
    return rc == CURLE_OK ? 0 : 1;
}

A C API, so the callback plumbing is more verbose than the others, and you will want a small RAII wrapper around CURL* in real code. In exchange you get an HTTP client that has been ported to more platforms than anything else on this list, with protocol coverage none of the others match. It also produced the smallest binary in this build — though that figure counts a libcurl.so that is already on the system, which the table below explains.

cpp-httplib — one header for plain HTTP

#include "httplib.h"
#include <iostream>

int main() {
    httplib::Client cli("http://127.0.0.1:8080");
    if (auto res = cli.Get("/")) {
        std::cout << "status " << res->status << "\n";
        std::cout << "bytes  " << res->body.size() << "\n";
    } else {
        std::cerr << "request failed: " << httplib::to_string(res.error()) << "\n";
        return 1;
    }
    return 0;
}

Drop one header into your project and, for plain HTTP, you are done — no package manager, no link step beyond -lpthread. HTTPS is a different matter. Define CPPHTTPLIB_OPENSSL_SUPPORT and you are linking OpenSSL like everyone else; omit the libraries and the build fails:

undefined reference to `EVP_MD_CTX_free'
undefined reference to `EVP_MD_CTX_new'
undefined reference to `EVP_DigestInit_ex'

With -lssl -lcrypto it builds. The single-header convenience is real, and it applies to the transport you are least likely to use in production. That convenience costs compile time and binary size, since everything is inlined into your translation unit. It is synchronous by default, which suits tools and tests better than servers.

Boost.Beast — closest to what the SDK was for

#include <boost/beast/core.hpp>
#include <boost/beast/http.hpp>
#include <boost/asio/connect.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <iostream>

namespace beast = boost::beast;
namespace http  = beast::http;
using tcp = boost::asio::ip::tcp;

int main() {
    boost::asio::io_context ioc;
    tcp::resolver resolver(ioc);
    beast::tcp_stream stream(ioc);
    stream.connect(resolver.resolve("127.0.0.1", "8080"));

    http::request<http::string_body> req(http::verb::get, "/", 11);
    req.set(http::field::host, "127.0.0.1");
    req.set(http::field::user_agent, "beast-demo");
    http::write(stream, req);

    beast::flat_buffer buffer;
    http::response<http::string_body> res;
    http::read(stream, buffer, res);

    std::cout << "status " << res.result_int() << "\n";
    std::cout << "bytes  " << res.body().size() << "\n";

    beast::error_code ec;
    stream.socket().shutdown(tcp::socket::shutdown_both, ec);
    return 0;
}

The most code for the simple case, and the only one of the three that gives you what the SDK’s users actually chose it for: asynchronous composition, WebSockets, and control over the connection. If your existing code leans on PPL tasks and http_listener, Beast plus Asio is the closest structural match. If it only ever made a few GET requests, this is more machinery than you need.

The Same Request, Four Ways

All four programs, same local server, same flags, same session:

The measured table below says these four libraries do the same job. At the level of one GET request they do. They are not interchangeable beyond that:

Two rows do most of the work here. The SDK bundles JSON and a URI type; none of the replacements does, so migrating the HTTP call is not the same as migrating the code. And “async” is not one feature — Beast’s asynchrony comes from Boost.Asio and its execution model, which is a larger commitment than swapping a client class.

Read the size column carefully. It is not a like-for-like comparison. libcurl’s 14 KB links against a shared libcurl.so that is already on the system and is not counted; cpp-httplib’s 1 MB is everything compiled into the binary because it is header-only. The column tells you about linkage models, not about efficiency. What it does show fairly is that none of these is a heavyweight choice for a simple client, and that the archived SDK is not notably lighter or heavier than its replacements.

The more useful finding is the first two columns: every one of them, including the archived SDK, compiled without a warning and returned the same response. The case for migrating is not that the alternatives work better today. It is that they will still be getting fixes next year.

What these runs do not show. Every request was plain HTTP to 127.0.0.1. Nothing here exercised TLS, proxies, redirects, timeouts, retries, chunked transfer, compression, authentication, malformed responses, concurrency or cancellation — which is where these libraries actually differ, and where an unmaintained one carries the most risk.

What Else You Are Migrating

Replacing http_client is the easy part, and an article that stopped there would be misleading. Inventory these before estimating the work:

• web::json::value — the SDK ships JSON. None of the three alternatives does. You will be choosing a JSON library as well, and porting every parse, every serialisation and every null-versus-missing check.
• utility::string_t — a typedef that is std::wstring on Windows and std::string elsewhere, along with the U() macro wrapping every literal. Other libraries use std::string throughout, so the conversions have to go somewhere.
• web::uri and web::uri_builder — libcurl has parsing helpers; Beast and cpp-httplib leave URI handling to you.
• PPL tasks — this is the hard one. It is not a return-type substitution: continuation scheduling, cancellation tokens, exception propagation across .then() chains and task composition all have to be mapped deliberately onto whatever you move to, whether that is std::future, Asio’s completion model, or C++20 coroutines.
• http_listener — always marked experimental, and the piece with no straight replacement. Routing, listener lifecycle, concurrency and TLS termination are all yours to rebuild. Start here, because it will set the timeline.
• Authentication, proxies, timeouts, retries and redirects — configured through the SDK’s own types. Each alternative spells them differently.

The HTTP call is usually a day. The list above is what makes it a project.

If You Are Staying On It For Now

That is a legitimate choice for working code on a stable toolchain, provided it is a decision rather than an oversight:

• Pin your version. 2.10.19 is the last one. Vendor it or pin the package so a distribution upgrade does not move underneath you.
• Know your fork is the support plan. The README says so explicitly — you may fork and continue development independently. That is now the only route to a fix.
• Watch the toolchain, not the library. Nothing will change upstream. The thing that will break you is your own compiler upgrade.
• Treat security as unowned. No upstream patches are coming. That is not a claim that a vulnerability exists today — it is that if one is found, assessing and fixing it becomes your job, a downstream packager’s, or a fork’s.
• Migrate the edges first. The client code is usually straightforward to port; http_listener was always experimental and is the hardest piece to replace, so start there rather than leaving it until last.

Key Takeaways

• The microsoft/cpprestsdk repository was archived on 1 June 2026 and is read-only. 2.10.19 is the final version.
• Microsoft’s own README names libcurl and Boost.Beast as the alternatives. cpp-httplib is a reasonable third option for simple clients.
• It still installs and still works on GCC and Clang. Compiled clean with zero warnings here and returned HTTP 200 — being archived did not change its behaviour.
• It does not compile on current MSVC toolsets, because its headers use stdext::checked_array_iterator, which MSVC removed. That bug is reported, small, and now unfixable upstream.
• Package managers still ship it. apt install libcpprest-dev succeeding tells you nothing about maintenance status.
• Choose by what you actually need: libcurl for the smallest, most portable client; cpp-httplib for a single header and no linking; Boost.Beast for async, WebSockets and protocol control.
• If you stay, pin the version and watch your compiler, not the repository. Nothing there will move again.

Frequently Asked Questions

Conclusion

The honest answer to “should I use the C++ REST SDK?” changed on 1 June 2026, and it changed in a way that does not show up when you compile. The library does what it always did. What it no longer has is anyone to fix it when your compiler moves, and on MSVC that has already happened.

For new work, take Microsoft’s advice and pick libcurl or Boost.Beast, or reach for cpp-httplib if the job really is just a handful of requests. For existing work on a toolchain that still builds, there is no emergency — but there is a deadline you do not control, and the time to plan for it is while everything still works. Our other C++ programming guides cover the surrounding ground, including Windows sockets programming if you are working closer to the network layer.

What I Could Not Verify

Everything was compiled and run on one machine: an Ubuntu 24.04 VM with g++ 13.3 and clang++ 18.1.3, against a local Python HTTP server on 127.0.0.1. I did not test on Windows or macOS, so the MSVC failure is reported from the upstream issue report rather than reproduced here — I have read the error and the cause, not seen it on my own machine. The four programs made plain HTTP requests to localhost; none of the TLS paths was exercised, which is where the differences between these libraries are largest and where an unmaintained library’s lack of security fixes matters most. The binary sizes compare different linkage models and should not be read as an efficiency ranking. cpp-httplib was taken from master rather than a tagged release, so its exact behaviour will drift. The archive date, the README wording and the list of alternatives were read from GitHub on the day of writing; the status of an archived repository does not change, but the ecosystem around it will.