in Software Development

C++ REST API frameworks benchmark

PHP, Python, C#, Java and Ruby are popular candidates to create REST API. But what about work horses like C and C++?

I decided to investigate most popular C++ frameworks for REST APIs creation and measure their performance relatively to PHP.

Source code of benchmark is freely available on, as well as Vagrant virtual machine to easily reproduce my measurements.


Language : Framework Max time amongst 98% of requests
ms, smaller is better
Average requests per second
#/sec, larger is better
Lines of code in sample
#, count without blanks
C++ : cpprestsdk / default JSON implementation 51 30.70 48
C++ : cpprestsdk / RapidJSON 44 47.06 47
C++ : restbed 7 224.18 39
C++ : pistache 6 319.99 40
PHP : Native implementation 10 146.95 14

In short, HTTP request handler that was done in pistache is fastest C++ implementation. C++ implementation is 2.17 times faster than PHP implementation of handler. However, PHP implementation is easier to maintain, because JSON/HTTP support is one of core language’s features, and therefore code is more compact.

C++ : cpprestsdk

cpprestsdk benchmark results (default JSON implementation)

cpprestsdk benchmark results (default JSON implementation)

cpprestsdk benchmark results (RapidJSON)

cpprestsdk benchmark results (RapidJSON)

(+) Code documentation of cpprestsdk is one of the best amongst all projects that I have ever seen during my 8 years carreer as software developer. Examples are well structured and easy to reproduce.

(+) cpprestsdk has its own implementation of JSON serializer/deserializer, so you don’t need to additionally include RapidJSON or other library.

(+) cpprestsdk is included in Ubuntu 16 Xenial official repository, so you can install it easily by running single `apt` command.

(+) Licensed under MIT.

(-) Worst performance (even worse than PHP) on Linux server. There is opened issue for this problem on project’s github (, but it is not solved yet.


C++ : restbed

restbed benchmark results

restbed benchmark results

(+) Good documentation on design of framework.

(+) Small and easy to use.

(-) No inline code documentation.

(-) Licensed under either AGPL or proprietary license.

(-) Some important features are still missing, e.g. server-side caching and HTTP2 compliance.


C++ : pistache

pistache benchmark results

pistache benchmark results

(+) Fastest performance.

(+) Small and easy to use.

(+) Licensed under Apache License 2.0.

(-) No inline code documentation.

(-) No comprehensive list of implemented features.

(-) Installation instructions are not present in repository and not obvious to find (you should look on “Getting started” page, not on “User’s Guide” FYI).

(-) Unit tests are ill-formed.


PHP native implementation

PHP native implementation benchmark results

PHP native implementation benchmark results

Write a Comment


This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. I have to pick a library for REST but i dont have any experience with it.
    In your personal opinion what library would you recommend for a simple use case.

    use case
    REST API for : creating an object, starting a thread inside the object that does stuff, destroying the object, getting some data from the object (prob with json for simplicity) and doing some manipulation of the object (look at it like changing settings).

    So low data overhead. Up to 100 devices max to manage by the master.
    I considered RPC but i think REST will be easier to integrate into a browser app.

    • Hi rinn2883,

      Thanks for the message!

      REST suits for CRUD operations perfectly, since REST resources often map to business entities. It is hard to tell if it suits for your specific case, because this description is too generic.

      P.S. I received your email and replied. Please, check inbox.

  2. It seems that REST SDK C++ has been improved in terms of network subsystem in last versions. I’ve got the next results:
    1) Rest SDK with Native JSON: ~30 req/sec (still slow because of its native json).
    2) Rest SDK with Rapid JSON: ~130 req/sec (huge improvement!)
    3) Restbed with Rapid JSON: ~100 req/sec (still faster than Rest SDK with native json).

  3. I have two web services created with `ngrest` and `pistache`. They are both inaccessible from another computer when using `192.168.1.XXX:port`. Adding listening port to `/home/USERNAME/nginx-build/nginx-1.14.0/conf/nginx.conf` only causes nginx to take control of that port, and the web services fail to run due to the port being occupied. I realize that this is a rather systemic problem, as it happens with both `pistache` and `ngrest`.

    Can someone show me what I got wrong, and what do I need to do to make my services accessible from another computer? Thanks.

    • Hi Nguyen,

      ngrest/pistache/other REST libraries usually implement their own web server, so you don’t need Nginx in front of them in the simplest case. Obviously, if you want to make load balancing with Nginx, you will need to forward request to your RESTful service like in, but skip it for now. Make it work first in simplest case (when Nginx is not used), then in more complicated.

      First of all, make sure that your services are running on server. Log into server’s terminal and try to send simple CURL request to your service, like `curl -XGET` (where 9000 is port for your RESTful service). If you will receive expected result, then the problem is not with your code, but rather with server configuration.

      You need to make sure that firewall on your OS allows access via port remotely (e.g. if you have service on for server with IP, make sure that port 9000 is accessible on from outside by running `curl -XGET` or like; also make sure that you don’t hit into VM strange behaviors if you are trying to access your services hosted in VM from outside – see,

      Hope this helps!


  4. Would be interesting to know the results on multithreaded clients – your concurrency is set to 1 on your “ab” command – maybe run more real life scenario, with 10, 25, 50 concurrent clients as well.