In my previous post I shown how you can build a C++ application with the C++ REST SDK that fetches search results from a search engine. In this post I will go a step further and develop a client-server application from scratch using version 1.1.0 of the SDK. This version features an HTTP listener implementation (still in an experimental phase). Notice that for the time being this 1.1.0 SDK release does not work with Visual Studio 2013 Preview. This samples and built with Visual Studio 2012.

Overview of the problem to solve

The server manages a dictionary of key-value pairs (both strings) and supports several HTTP request methods:

  • GET: retrieves all the key-value pair from the dictionary.
    The response is a JSON object representing key-value pairs (eg. {"one" : "100", "two" : "200"}).
  • POST: retrieves the values of the specified keys from the dictionary.
    The request is a JSON array of strings (eg. ["one", "two", "three"]).
    The response is similar to the GET method, except that only requested keys are returned.
  • PUT: inserts new pairs of key-values in the dictionary. If a key is already found its value is updated.
    The request is a JSON object representing pairs of keys and values (eg. {"one" : "100", "two" : "200"})
    The response is a JSON object representing they key and the result for the action, such as addition or update (eg. {"one" : "<put>", "two" : "<updated>"}).
  • DEL: deletes the specified keys from the dictionary.
    The request is a JSON array of strings (eg. ["one", "two", "three"]).
    The response is a JSON object representing they key and the result for the action, such as success or failure (eg. {"one" : "<deleted>", "two" : "<failed>"}).

Notice that the server implements both GET and POST. The GET method is supposed to request a representation of the specified URI. Though it is theoretically possible that a GET request carries a body, in practice that should be ignored. The C++ REST library actually triggers an exception if you make a GET request with a body. Therefore, GET is used to return the entire content of the dictionary and the POST method, that supports a body, returns only the requested key-value pairs.

The client can make HTTP requests to the server, adding or updating key-values, fetch or delete existing pairs.

All communication, both for the request and the answer, is done using JSON values.

The server implementation

On the server side we have to do the following:

  • instantiate an http_listener object, specifying the URI where it should listen for requests.
  • provide handlers for the HTTP request methods for the listener.
  • open the listener and loop to wait for messages.

The core of the server application is shown below (except for the request handlers).

In this simple implementation the dictionary is a std::map. Its content is not persisted to disk, it is reloaded each time the server starts.

Let’s now look at the handlers. As mentioned earlier the GET method is a bit different than the others. A GET request should return all the key-value pairs in the server’s dictionary. Its implementation looks like this:

What it does is iterating through the dictionary and putting its key-value pairs into a json::value::field_map. That object is then sent back the the client.

The POST, PUT and DEL methods are a bit more complicated, because they all receive a JSON value specifying either keys to fetch or delete or pairs of key-value to add or update in the dictionary. Since some code would get duplicated several times I have created a generic method for handling requests that takes a function that evaluates the JSON request value and builds the response JSON value.

The handlers for POST, PUT and DEL will then call this generic method providing a lambda with the actual core implementation of each request handling.

And that is all with the server.

The client implementation

On the client side we need a http_client object to make HTTP requests to the server. It has an overloaded method request() that allows specifying the request method, a path and a JSON value for instance. A JSON value is not sent if the method is GET (or HEAD). Since for each request the answer is a JSON value, I have created a method called make_request() that dispatches the request and when the response arrives it fetches the JSON value and displays it in the console.

The core of the client code looks like this:

In the main() function I then just make a series of requests to the server, putting, fetching and deleting key-values from the server’s dictionary.

The client and server in action

You need to start the server first and then run the client. The output from running the client is:

On the server console the output is:

, , , , , , Hits for this post: 11565 .
Trackback

10 comments untill now

  1. Gravatar
    Fernando @ 2013-11-06 21:21

    How to put the listener to listen on 0.0.0.0?

    like http_listener listener(L”http://0.0.0.0:9000/restdemo”);

    not work

  2. Gravatar

    IP address 0.0.0.0 is used to designate an invalid address (usually used when a machine is not connected to a TCP/IP network). Why would you expect this to work?

  3. Gravatar
    Fernando @ 2013-11-11 13:12

    IP address 0.0.0.0 is not invalid.

    It listen on all interfaces on *this* network (my networks).

    http://tools.ietf.org/html/rfc5735#section-3

  4. Gravatar
    Fernando @ 2013-11-11 20:12

    With http_listener listener(L”http://*:9000/restdemo”); it works fine.
    Thanks

  5. Gravatar
    Steven Starr @ 2013-11-12 23:43

    [quote]
    IP address 0.0.0.0 is used to designate an invalid address (usually used when a machine is not connected to a TCP/IP network). Why would you expect this to work?
    [/quote]

    Your joking right? There are literally hundreds of reasons why your wrong.

  6. Gravatar

    Address 0.0.0.0 is a convention to designate ALL interfaces. In the use case posed by Steven, it would listen on all addresses including 127.0.0.1. This convention has been in use for decades for *nix operating systems..

    It would be helpful to adhere to a widely used convention..

  7. Gravatar

    Sorry, as I can get the file http_client.h

  8. Gravatar

    why is this used?

    while (true); //line 38 in the first snippet

    Chris

  9. Gravatar
    Rotem Bentzur @ 2014-05-31 09:58

    I can’t help but notice the busy wait in the server code. I’m referring to the while (true) statement?
    Why is it there? Any other way?

  10. Gravatar
    Igor Sadchenko @ 2014-07-19 21:14

    Hi
    I have this error
    no callable ‘begin’ function found for type ‘web::json::value’

Add your comment now