 |
Home | Documentation |
XML-RPC/JSON and jsoncpp
updated Mon Apr 22 2024 by Robert van Engelen
|
|
Home | Documentation |
XML-RPC/JSON and jsoncpp
updated Mon Apr 22 2024 by Robert van Engelen
|
XML-RPC predates JSON and shares the same goal to offer a simple data format for Web applications that interoperate via "remote procedure calls" (RPC) over "stateless" HTTP via HTTP POST. Applications are not limited to the exchange of RPC messages via HTTP POST. Other REST methods can be used to manage the state of resources via URL references, allowing for the storage of data (HTTP PUT), retrieval of data (HTTP GET), and removal of data (HTTP DELETE) from a resource.
XML-RPC is a generic, self-describing (and very verbose) XML format to compose XML messages for platform-neutral data exchange. XML-RPC defines a collection of frequently used XML types with common programming language equivalents. XML-RPC does NOT provide a data binding to XML and does NOT support a validation mechanism to ensure that data content is validated against a schema. XML-RPC serialization proceeds by marshaling parameters in predefined XML elements for each data type. XML-RPC has primitive types (bool, int, double, string, dateTime, base64) and two compound types (structs and arrays).
This document does not describe XML-RPC in detail. For more details, please visit http://www.xmlrpc.com.
JSON (JavaScript Object Notation) is an even simpler data format to support platform-neutral data interchange that is highly compatible across programming languages by restricting data representation to a set of five common types: bool, number, string, array, and object. A JSON object is the same as an XML-RPC struct. Only the syntax differs. Both are composed of fieldname-value member pairs (i.e. dictionaries or hashmaps) and have no other special properties. Which is in contrast to XML data "as objects" that are namespace scoped and may include xsi:type attributes to distinguish derived from base types, and may include id-ref attributes to cross-reference data, and other properties that make XML more suitable to achieve lossless C/C++ serialization.
This document does not describe JSON (and JSON RPC/REST) in detail. For more details, please visit http://www.json.org.
This document describes both the C and C++/C++11 XML-RPC and JSON library APIs, see table of contents.
The gSOAP JSON API is compact and lightweight. It is straightforward to write JSON RPC and JSON REST code. For example, a JSON REST call in C++ to a JSON REST server on port 8080:
For more details on JSON-RPC and JSON REST operations, see C++ JSON-RPC clients and servers .
To compile this example see the List of files .
Furthermore, to help you quickly develop C/C++ JSON code, we offer a code generator jsoncpp with the gSOAP package (version 2.8.26 and up). You can find the jsoncpp tool with the JSON examples in gsoap/samples/xml-rpc-json.
The jsoncpp command-line tool auto-generates C or C++ code from a JSON fragment. The generated code creates a JSON node graph for this fragment, which can be further tweaked as necessary. We demonstrate this on an example menu.json file, where we show each command executed in a command shell followed by the results displayed in the terminal:
cat menu.json
jsoncpp menu.json
You can use jsoncpp option -e to add explanatory comments to the generated code, which explains what the code does to help you understand the JSON API.
Use jsoncpp option -M to narrow the generated code down to the essentials, without the initialization and cleanup parts of the code. This makes the generated code suitable for direct inclusion in your codebase.
Generating code to populate a node graph is one option. Another option is to generate code to inspect a node graph. Use jsoncpp option -i (gSOAP 2.8.28 and up) to generate code to inspect the node graph of a value parsed from JSON input, given that the JSON file provided with option -i serves as a generic template:
jsoncpp -i menu.json
As you notice, each access to deeper JSON values in objects is guarded by a check that the object property is present. This helps to identify missing data in the JSON data received, but this checking is not strictly necessary to access values. When a non-existent obect property is accessed, its value returned is null. For example, you can access x["menu"]["id"] directly to obtain the id value, even when menu is not an object because this will cast menu into an object (i.e. internally changing the JSON graph without triggering exceptions or errors):
jsoncpp -k menu.json
On the other hand, checking for the presence of data before accessing it preserves its original structure, which may be important with respect to the type of application that uses JSON.
The two examples above display the JSON values with the macro USE_VAL, which takes a JSON val of type value.
Furthermore, we can assign the JSON values to auto-generated local variables using option -l with options -i or -k:
jsoncpp -k -l menu.json
JSON values of type value can be easily cast to and from C/C++ types, see Overview for details.
You can also use the new jsoncpp option -p (gSOAP 2.8.27 and up) to generate efficient JSONPath query code to query and retrieve specific values.
For example, let's write a JSONPath query to display the authors of books in a store. We will read the JSON data from std:cin and filter the authors with the query $.store.book[*].author to collect them in a JSON array y of results with jsoncpp option -y. We generate the code from the command line with jsoncpp as follows:
jsoncpp -M -p'$.store.book[*].author' -y
Let's apply this query to the store.json file that you can find in section JSONPath by example :
./query < store.json
You can compile this example yourself with:
jsoncpp -o query.cpp -m -p'$.store.book[*].author' -y soapcpp2 -CSL xml-rpc.h c++ -o query query.cpp json.cpp xml-rpc.cpp soapC.cpp stdsoap2.cpp
You can also embed C/C++ code in JSONPath queries to filter and select values from JSON data at runtime.
The jsoncpp code generator aims to produce clean, high-quality and readable C and C++ code. We will present jsoncpp in more detail in the next section. The remainder of this document explains how you can use the XML-RPC/JSON C and C++ APIs to create JSON data, access JSON data, send/recv data via REST, and to read/write JSON data to files, streams, and string buffers.
It should be stated that JSON as a data format is not a true-and-tested alternative to XML and XML schema. XML data bindings provide a strongly typed interface to exchange validated data with RPC and REST. However, XML can be more complex to provide strong guarantees for object polymorphism (base and derived classes), to accurately represent tree and graph structures, to include binary content natively with base64 (and mechanisms for streaming MIME/MTOM attachments), to support extensibility (to extend data types and to add new data types), and schema namespaces referenced by XML elements and attributes to avoid ambiguity.
The jsoncpp command produces high-quality, readable and reusable source code. The generated code can be readily used in your projects to populate JSON data and retrieve data, thereby saving you substantial time and effort to write code. You may not have to write any C or C++ code to manipulate JSON data with your application's code base when taking full advantage of the jsoncpp autocoding tool.
The jsoncpp command-line tool generates C or C++ source code to populate a JSON node graph with the data given in a JSON file. The command also has an option -i to generate source code to inspect parsed JSON values by using a JSON file as a generic template for this code. And option -p generates efficient source code for JSONPath queries. Even stand-alone JSONPath query filter applications can be auto-generated with option -m (for main).
You will find jsoncpp and the XML-RPC/JSON examples in the gSOAP package in gsoap/samples/xml-rpc-json.
To build jsoncpp, install gSOAP and build jsoncpp as follows:
cd gsoap/samples/xml-rpc-json make jsoncpp
This builds the command-line tool jsoncpp in gsoap/samples/xml-rpc-json from where you can use it and/or copy it for use with your projects.
If you do not have the samples built, you can use soapcpp2 from the command line to generate the C++ code required to compile jsoncpp and that is also required by the C++ JSON API components:
cd gsoap/samples/xml-rpc-json soapcpp2 -CSL xml-rpc.h c++ -I../.. -o jsoncpp jsoncpp.cpp json.cpp xml-rpc.cpp soapC.cpp ../../stdsoap2.cpp
This builds the jsoncpp command-line tool.
For users of Windows, visit download and installation to download jsoncpp.exe.
The jsoncpp command takes several options and an optional JSON input file:
jsoncpp [-c] [-e] [-f%fmt] [-h] [-i] [-k] [-l] [-m] [-M] [-O] [-ofile] [-ppath] [-rroot] [-xcode] [-y] [infile]
where the jsoncpp command-line options are:
| Option | Description |
|---|---|
-c | generate C code instead of C++ |
-e | add explanatory comments to the generated code |
-f%fmt | use %fmt to format double floats, e.g. -f%lG |
-h | display help message |
-i | generate code to inspect JSON node graph with data type checks |
-k | generate code to inspect JSON node graph directly without checks |
-l | generate code for option -i to store values in local variables |
-m | generate stand-alone code by adding main() |
-M | generate minimal code unadorned with initialization and cleanup |
-O | optimize code by factoring common indices |
-ofile | save source code to file |
-ppath | generate JSONPath query code for path |
-rroot | use root instead of root value x in the generated code |
-xcode | generate code that executes code for each JSONPath query result |
-y | generate code that yields an array y of JSONPath query results |
infile | optional JSON file to parse |
- | read JSON from standard input |
The jsoncpp command takes a JSON input file infile to generate code to construct this JSON value in C/C++ or, with options -i or -k, to generate code that reads JSON data from input and traverses it to inspect its value by using the JSON input file infile as a template to match against. For options -i and -k, if you want additional code that uses local variables to store boolean, integer, and floating point values retrieved from the JSON node graph, then also use option -l.
Use option -c to generate C code instead of C++ and use option -e to add explanatory comments to the generated code.
The jsoncpp command emits source code to standard output or to the file specified with option -o.
Minimalistic code is generated with option -M, which is useful to automate pasting of the unadorned source code into the source code of your project.
Optimized code is generated with option -O by factoring common array indices and object field names. This produces more elaborate code that is more efficient but may be harder to read and modify. This option has no effect on the code generated with options -i and -k.
The default name of the root value in the generated source code is x. To change this name use option -r. Do not use the name v, which represents the current value. Other variable names to avoid are i, j, k, p, q, r, s, and S, since these are internally used by the generated JSONPath query code.
Use option -p to generate code that filters JSON data from a source of input with a JSONPath query path. Option -x specifies a JSONPath query code to execute for each query result. The default action in the generated code is to print each query result value in JSON format separated by newlines. Option -y yields a JSON array of query result values that are incrementally collected. Option -x overrides option -y.
To generate a stand-alone application use option -m. This option is useful for testing JSONPath query filters given with option -p.
Option -f%fmt sets the floating point double precision format to use in the generated code. By default, jsoncpp emits floating point numbers with up to 17 digit mantissas to preserve precision. Use -f%lG for the shortest floating point representation.
The concept behind JSONPath is identical to XPath for XML: to select elements (value nodes) from a DOM node structure of a document by matching the path expression against descendent nodes in the node tree structure. A JSONPath query returns the JSON values selected.
We adopt the JSONPath syntax suggested by Goessner, but extended with ? ("where") and ! ("where not") operators. Our JSONPath syntax also supports the [?(expr)] and [(expr)] constructs to insert your own C/C++ expressions for filtering and selection of nodes in JSONPath queries. Our syntax also supports multiple comma-separated alternatives in the [ ] selector. But the syntax does not support | (alternation). We recommend to write a JSONPath query for each alternation.
JSON data structures are represented internally as a node graph consisting of atomic values (null, bool, int/double, string), arrays, and "objects". JSON objects are structs with fieldname-value pairs. A JSONPath expression specifies a JSON data query, typically starting from the root node, and descending deeper into the node graph to match child nodes.
For example, suppose we have a store object with a book array. Each book object has a title string and some other properties which we will ignore for now. The following JSONPath query returns the titles of all books in the store:
$.store.book[*].title
We can also write the same query in bracket notation:
$["store"]["book"][*]["title"]
Note that the syntax of this query has a close similarity to the C++ JSON API for accessing object fields (a.k.a. object properties) and array elements.
Basically, a JSONPath expression is a sequence of operations to match nodes:
| Operator | Nodes matched and returned |
|---|---|
$ | the root node of the node graph |
.f or [f] | child node at field named f of the current object node |
[n] | nth node of the current array node, if indexed within bounds |
[b:e:s] | array slice of the current array node |
[x,y] | child nodes matching x or y (fields, indices and slices) |
* | "wildcard": any child node of the current object/array node |
.. | "recurse": any matching descendant nodes of the current node |
? | "where": current node if the rest of the query path matches |
! | "where not": the complement of ? |
[(e)] | use value of C/C++ expression e to match a field or index |
[?(e)] | evaluate C/C++ expression e, continue matching when true |
Field names (f in the table) in JSON and in JSONPath queries may contain UTF-8 Unicode characters.
Throughout this document we refer to the field names of objects and structs. Also commonly used are JSON object property names and key names (as in key-value pairs),
Other JSONPath implementations require quotes for field names in brackets, as in ["store"]. With jsoncpp you will only need to add quotes when field names contain control characters, spaces, or punctuation, such as a unit-price field name in the query $..["unit-price"]. To promote orthogonality of the JSONPath syntax (no arbitrary rules and exceptions depending on a context), quoted field names are also valid with dot notation in our JSONPath syntax, such as the query $.."unit-price".
A JSONPath query expression uses dot or bracket operators to match JSON data located at increasingly deeper levels of the data structure.
Consider the following JSON data:
To match the title of the first book (book[0]) in a store, starting at the root node indicated by $, we use the following JSONPath query expression:
$.store.book[0].title
This query returns "Sayings of the Century" when applied to the JSON data.
To try the JSONPath examples yourself, we suggest to create a store.json file with the above JSON data and run jsoncpp from the command line to compile a JSONPath query as follows:
cd gsoap/samples/xml-rpc-json soapcpp2 -CSL xml-rpc.h jsoncpp -o test-json.cpp -m -p'$.store.book[0].title' c++ -I../.. -o test-json test-json.cpp json.cpp xml-rpc.cpp soapC.cpp ../../stdsoap2.cpp ./test-json < store.json
The compiled JSONPath query is applied to the store.json data and returns the matching values found. Use jsoncpp option -y to return matches in a JSON array.
The soapC.cpp file, and the header files soapStub.h and soapH.h, are generated with the command soapcpp2 -CSL xml-rpc.h, which is done just once for all C++ JSON applications. Use soapcpp2 option -c to generate soapC.c for C (with the corresponding soapStub.h and soapH.h in C).
To match any field of an object or any array element, we use a wildcard *:
$.store.*.price
This matches and returns the bicycle price 19.95, but not the book prices that are located one level deeper in the array of books, which can be matched with:
$.store.*.*.price
This returns the values 8.95, 12.99, 8.99, and 22.99.
Note that in the latter case we only get the book prices, because the first * matches book and bicycle and the second * matches the book array and the red and price fields. Only the book prices are returned, because red and price are atomic and have no price child node.
To match and return all prices in the store we use .. called "recursive
descent" or simply "recurse", as follows:
$..price
Array elements are matched with brackets [n] where n is an array index. Negative indices can be used to access array elements from the end of an array, where -1 refers to the last element. We can list the array elements to match with [x,y], for example:
$.store.book[0,1,-1].title
This matches and returns the titles of the first two books and the last.
JSONPath queries do not modify the node graph searched. So you do not need to worry about indices that are out of bounds or fields that are not part of an object.
Arrays can also be sliced for matching from a starting index b until (excluding) an ending index e with [b:e], where b and e values are optional. When omitted, the slice runs from the start and/or from the end of the array.
For example:
$.store.book[:].title
matches and returns the titles of all books in the store, and
$.store.book[:2].title
matches and returns the first two books (at 0 and 1) in the store.
We can use an optional step s to slice arrays with [b:e:s] and even reverse array element-by-element matching with a negative unit step:
$.store.book[::-1].title
This matches and returns the titles of all books in reverse order.
The following JSONPath queries return the same results for the example JSON data, where we used slices and [x,y] to match multiple array entries:
$.store.book[1:3].title $.store.book[1:-1].title $.store.book[-3:-1].title $.store.book[1,2].title $.store.book[-3,-2].title
Basically, JSONPath array slices in our implementation follow the intuitive Python array slice syntax and meaning. Beware that many other JSONPath implementations do not implement the step parameter consistently or do not support stepping.
Note that [:] is not the same as [*] because [:] only matches arrays.
A conditional JSONPath expression contains a ? ("where") operator. The operator returns the results that match the left side of the ? but only when the right-side matches:
$.store.book[:]?isbn
This matches and returns only books that have an isbn field.
The complement of the ? operator is ! ("where not"), which returns the results that match the left side of the ! but only when the right-side does not match.
More complex queries can be formulated by embedding C/C++ expressions in the query to filter [?(e)] and select [(e)] nodes. For example, in C++:
$.store.book[:][?((double)v["price"] < 10.0)].title
and in C:
$.store.book[:][?(*double_of(value_at(v, "price")) < 10.0)].title
This filters books with prices lower than 10.0 and returns the title of each book found.
Embedded C/C++ expressions to filter nodes can inspect the current JSONPath node value by accessing variable v, as is shown above. Here we used (double)v["price"] to obtain the price of the current node for comparison. Besides the current node v you can also access the JSONPath root node value x. Instead of the default name x, you can change x to another name with jsoncpp option -r.
You can access variables and functions in embedded C/C++ expressions, but do not access or modify i, j, k, p, q, r, s and S, which are internally used by the generated JSONPath query code.
v["price"] will add a price to any current node value v that has no "price" field! To make field accesses safe we should first check if the field exists in the current node before we access it: $.store.book[:][?((v.has("price") ? (double)v["price"] : 9999) < 10.0)].title
has() is the only safe way to combine .. with C/C++ filters, since we may visit all nodes in the graph, for example to find all prices < 10.0: $..[?((v.has("price") ? (double)v["price"] : 9999) < 10.0)].price
Object fields and array elements can be accessed in a JSONPath query with C/C++ expressions that evaluate to string field names or to integers indices, respectively. For example, we can use the string argv[1] of main() as a field name in C++:
$.store.book[:][(argv[1])]
In C we have to explicitly use value_at to access the field of the current v node (and we use nth_value to access array elements of the current v node, not shown here):
$.store.book[:][(value_at(v, argv[1]))]
This assumes that the command-line argument (argv[1]) of the application is a book field name. Otherwise, no results are returned.
After compiling the JSONPath query with
jsoncpp -o test-json.cpp -m -p'$.store.book[:][(argv[1])]' c++ -I../.. -o test-json test-json.cpp json.cpp xml-rpc.cpp soapC.cpp ../../stdsoap2.cpp
we can obtain the book titles with:
./test-json title < store.json
You can use multiple C/C++ expressions in brackets and combine them with other field and array expressions separated by commas:
$.store.book[:][title,(argv[1])]
This prints the title and the value of the field name given by the command-line argument, if there is a field that matches the given name.
Finally, let's use the value of argv to filter products in the store by a given command-line argument price:
jsoncpp -m -p'$.store..[?((v.has("price") ? (double)v["price"] : 9999) < strtod(argv[1], NULL))]'
And in C:
jsoncpp -c -m -p'$.store..[?((nth_at(v, "price") >= 0 ? *double_of(value_at(v, "price")) : 9999) < strtod(argv[1], NULL))]'
C/C++ expressions cannot be used as array slice bounds, which must be constant.
XML-RPC and JSON data is interchangeable in this implementation, with the only exception that the dateTime and base64 types are handled as strings in JSON. Also, JSON's only numeric type is floating point. However, integers are handled just fine by this JSON implementation as 64 bit (i.e. long long, int64_t, LONG64) without internal conversion to/from double floating point values that could cause a loss of precision for large values.
The following files define XML-RPC operations and data types for C++:
xml-rpc-io.h: XML-RPC serialization over streamsxml-rpc-io.cpp: XML-RPC serialization over streamsxml-rpc-iters.h: iterators for structs, arrays, and XML-RPC parametersxml-rpc.cpp: XML-RPC C++ data binding APIxml-rpc.h: XML-RPC data binding as a gSOAP .h file for soapcpp2 (do not #include this file in your project builds)For JSON we use the following files for C++:
json.h: JSON C++ API and JSON serialization over streamsjson.cpp: JSON C++ API and JSON serialization over streamsxml-rpc.cpp: XML-RPC C++ data binding APIxml-rpc-iters.h: iterators for structs/objects and arraysxml-rpc.h: XML-RPC data binding as a gSOAP .h file for soapcpp2 (do not #include this file in your project builds)The gSOAP header file xml-rpc.h defines all XML-RPC and JSON types as struct with C++ member functions to create XML-RPC and JSON data and REST messages.
A note about the following auto-generated files: soapH.h, soapStub.h and soapC.cpp. These are required for XML-RPC and JSON. To auto-generate these files, execute:
soapcpp2 -CSL xml-rpc.h
Then compile and link the .cpp files listed above for XML-RPC and JSON with the auto-generated soapC.cpp and stdsoap2.cpp:
c++ -I../.. -o myapp myapp.cpp json.cpp xml-rpc.cpp soapC.cpp ../../stdsoap2.cpp
Instead of stdsoap2.cpp you can link libgsoap++.a with -lgsoap++, when installed by the gSOAP package.
To enable OpenSSL for HTTPS compile with -DWITH_OPENSSL and link -lssl, and -lcrypto:
c++ -DWITH_OPENSSL -I../.. -o myapp myapp.cpp json.cpp xml-rpc.cpp soapC.cpp ../../stdsoap2.cpp -lssl -lcrypto
For OpenSSL support, instead of stdsoap2.cpp you can link libgsoapssl++.a with -lgsoapssl++, when installed by the gSOAP package.
Because XML namespaces are not used, we can either use -DWITH_NONAMESPACES to compile stdsoap2.cpp without complaining about a missing global Namespace, or we can define an empty namespaces table somewhere in our code:
An XML-RPC/JSON data value is created in C++ as follows, which requires a context ctx with the engine state (the soap struct). The context manages the memory that is internally allocated to hold values:
Note that soapH.h is an auto-generated file (see previous section). This file needs to be generated only once and for all. It also references stdsoap2.h and the auto-generated soapStub.h. Compile and link your code with stdsoap2.cpp and the auto-generated soapC.cpp XML-RPC serializers. Also compile and link xml-rpc.cpp. For JSON, compile and link json.cpp.
We can stack-allocate local values as shown above. To allocate a value on the heap that is managed by the engine context, use new_value(ctx):
Allocating values on the heap may throw std::bad_alloc exceptions, but allocating a context does not. To safeguard your code use a try-catch:
You can use wide strings with Unicode stored in UTF-8-formattted 8-bit char strings. For compatibility with XML-RPC serialization of UTF-8-encoded strings, we MUST use the SOAP_C_UTFSTRING flag to initialize the context with soap_new1(SOAP_C_UTFSTRING). We can optionally use SOAP_XML_INDENT to indent XML and JSON.
The code shown above creates an empty value v. Values can be assigned any one of the following data types:
We can combine these operations in many possible ways to create arrays of arrays, arrays of structs, and so on. For example:
This creates a singleton array containing an object with two members: name set to "bob" and toys set to an array containing "ball" and "furby". In JSON format this is represented as:
[ { "name": "bob", "toys": ["ball", "furby"] } ]
^ ^ ^ ^
| | | |
an array_/ | | |
of 1 struct_/ | |
with 2 members_/______________/
Let's see what happens when we assign a variable the value of another.
The JSON C++ API uses the value model for variables with atomic values, meaning that atomic values are copied when assigning a target variable the atomic value of another variable. It uses the reference model for arrays and structs, meaning that array and struct contents are shared when assigning a target variable the array/struct value of another variable. We illustrate the effect below:
This prints x = 2 and y = 1 and a.num = 2 and b.num = 2.
You can make deep copies of values by using the auto-generated soap_dup_value function in soapC.cpp:
This prints a.num = 2 and b.num = 1.
soap_dup_value with new entries. The new entries may use unallocated memory. You can always loop over arrays and structs to copy their contents to a new array or struct managed by another context, if you must add new entries later.To auto-generate soap_dup_value, use option -Ec with soapcpp2:
soapcpp2 -Ec -CSL xml-rpc.h
With gSOAP 2.8.28 and later you can use the following operators on values in C++:
| Operator | Type of JSON Value Operands | Result after Operand Type Promotion |
|---|---|---|
+ | bool, number, string, struct, array | sum, string concat, struct concat, array concat |
-, *, /, % | bool, number | difference, product, division, modulo |
==, != | bool, number, string, struct, array | C++ bool |
<=, >=, <, > | bool, number, string | C++ bool |
The (un)equal operators compare the two values by deep value comparison of array elements and object fields and values. For the arithmetic operations, operands are converted by type promotion until the two operands conform to the type required for the operation:
atomic int double string struct array
false -> 0
true -> 1
int -> double
null -------------------> "null"
false ------------------> "false"
true -------------------> "true"
int -> double -> string
null ---------------------------------------> [null]
false --------------------------------------> [false]
true ---------------------------------------> [true]
int -------------------------------> [int]
double ---------------------> [double]
string -----------> [string]
struct -> [struct]
An example:
Arithmetic and concatenation operations may incur significant memory overhead due to temporaries, type conversions (when applicable), and managed heap storage. Use them only when CPU and memory usage are not critical.
When receiving a value in XML-RPC/JSON, we generally want to check its type to obtain its value. To check the type of a value, we use is_Type methods:
When working with JSON data, do not use is_double() but is_number(). JSON data does not differentiate between integers and floats. However, gSOAP makes sure that 64 bit integer values are accurately represented in JSON and decoded without loss from JSON. That is, when receiving an integer that you checked with is_int() you can then safely cast value with e.g. int64_t n = v.
The following methods can be used to inspect arrays and structs (JSON objects):
For example, let's take the value v that was assigned the array shown above. We have the following properties of this value:
When accessing structs (JSON objects) by field name, make sure to use existing member field names only. A new member fieldname-value pair is dynamically added to the structure to accomodate the new entry for the field.
Also arrays are extended to accommodate the indexed array element. A negative index accesses elements from the array's end, with index -1 accessing the last value. Also the value::has(int) and value::nth(int) methods take a negative index for bounds checking on arrays and will return false or negative, respectively.
Use value::size(int) to change array size or set arrays to zero length. Use negative size with value::size(int) to remove elements from the end.
You may want to use iterators to retrieve data from structs and arrays (see further below).
To retrieve atomic data we can use casts on a value v as follows:
It is valid to cast a primitive type to any of the other primitive types shown above and no runtime error will occur, although you may loose some information when an atomic value has no representation in the target type's value space. Casting a number to a string is fine, but casting a string to a number only gives a nonzero numeric value if the string is numeric. Casting a value to base64 produces its base64 encoding.
To access base64 binary raw data of a value v, we use the following methods:
Arrays and structs are compound types that cannot be cast to or from other types (but if you do cast, an empty array or struct is created an no runtime error will occur). So we should check for array and struct types to obtain their content. For example:
We use the iterators value::iterator and value::const_iterator to loop over the values in structs and arrays:
The iterator method value::iterator::index() returns the integer index of the struct or array element. The value::iterator::name() method returns the name of the struct member, or empty "" if the type is not a struct. The value::const_iterator does not permit the value referenced by the iterator to be modified.
There are two lower level iterators for structs and arrays, which are slightly more efficient to use compared to the value::iterator. These array and struct iterators have an index() method to obtain the index (an int). Struct iterators have a name() method to obtain a member's name (a string).
For example, to traverse a value v that is an array or a struct:
As usual, the _struct::const_iterator and _array::const_iterator do not permit the values referenced by the iterator to be modified.
XML-RPC parameter lists are similar to arrays and its values are indexed. We can also iterate over response parameters after an XML-RPC REST call:
We should note that JSON REST does not require parameter types, for example:
There are two additional methods to invoke on parameters:
All dynamically allocated memory that is internally used to store data is deallocated with:
Additional C++ examples are located in gsoap/samples/xml-rpc-json:
xml-rpc-currentTime.cpp: XML-RPC C++ client, also uses JSONxml-rpc-currentTimeServer.cpp: XML-RPC C++ server (CGI and multi-threaded stand-alone)xml-rpc-weblogs.cpp: XML-RPC C++ clientxml-rpc-json.cpp: XML-RPC to/from JSON examplejson-currentTime.cpp: JSON REST C++ clientjson-currentTimeServer.cpp: JSON REST C++ server (CGI and multi-threaded stand-alone)json-GitHub.cpp: JSON REST C++ client for GitHub API v3A typical XML-RPC calling sequence in C++ is:
Alternatively, parameters of a methodCall can be passed with the methodCall itself as follows:
Note that in the client code, after the response is retrieved, the implicit type casts done by assignments will retrieve the values that are type-cast converted if needed. These casts can be used anywhere to retrieve values:
Type casts can also be used to convert data, which means they never produce an exception. Casting to string (const char*) converts atomic values to strings, but does not convert compound types such as arrays and structs.
which prints a string representation of the int, double, boolean, time, or base64 values of parameters. An empty string is printed for arrays and structs. Use iterators to walk over arrays and structs to print values. Or use the JSON API json.h and json.cpp to print values in JSON format, see further on JSON below.
A typical C++ XML-RPC server sequence is:
With option 1 the server code above uses standard in/out and thus runs over CGI. Other possibilities are given by options 2 and 3.
To serve requests at a port, we use the soap_bind() and soap_accept() calls to bind the server to a port and accept requests via socket, see also the docs and examples for these calls (see for example gsoap/samples/webserver.c):
Note that we only have a queue of one with soap_bind(ctx, NULL, 8080, 1) which rejects multiple requests. Enlarge the queue as you wish, but beware that larger queues can lead to server access problems. Also set appropriate timeouts and message length limits, see the [tutorials](https://www.genivia.com/tutorials.html#How_to_harden_your_application's_robustness_with_timeouts_and_error_handlers)
To send and receive XML over streams, use xml-rpc-io.h and xml-rpc-io.cpp. For example:
which will display the data in XML-RPC format. To parse XML-RPC data from a stream, use:
Compile and link together with soapC.cpp, xml-rpc.cpp, xml-rpc-io.cpp, and stdsoap2.cpp.
To display values in JSON format or to parse JSON data, use the json.h and json.cpp JSON serializers in combination with xml-rpc.cpp and the auto-generated soapH.h and soapC.cpp. It is also possible to send and receive JSON data over HTTP as JSON REST operations, but this requires some more coding (see C++ JSON REST clients and servers below).
Because the internal data is the same for XML-RPC and JSON, You can write data in XML-RPC or in JSON format. You can also parse XML-RPC data and write to JSON data and vice versa.
To write JSON to a stream you can use the << operator on an output stream and a JSON value.
To parse JSON from a stream you can use the >> operator on an input stream and populate a JSON value.
For example, you can parse a JSON-formatted string and use that data to make an XML-RPC call. The result of the call is displayed in JSON, nicely indented using the SOAP_XML_INDENT flag (this XML indent flag also works for JSON):
To force reading and writing JSON in ISO 8859-1 format, use the SOAP_ENC_LATIN flag to set the context (not recommended).
Optionally use SOAP_XML_INDENT to indent XML and JSON.
To parse JSON values from a file or any other non-HTTP source, it is recommended to set the SOAP_ENC_PLAIN context flag to prevent the parser from attempting to read a MIME or HTTP headers (HTTP headers are required with JSON-RPC):
Compile and link your code together with soapC.cpp (generated), xml-rpc.cpp, json.cpp, and stdsoap2.cpp.
The JSON protocol has fewer data types than XML-RPC, so type information can be lost when serializing to JSON:
See the section on C++ examples on how to populate and retrieve C++ data.
Strings are stored and exchanged in UTF-8 format in 8-bit strings (char* and std::string) by using the SOAP_C_UTFSTRING flag. Wide strings (i.e. wchar_t* and std::wstring ) are converted to UTF-8.
To use JSON REST on the client side, we use json_call:
A json_call takes a context, an endpoint URL (with URL query string parameters as needed), and optional in and out values to send and receive, respectively. This function returns SOAP_OK (zero) for success or EOF, SOAP_SYNTAX_ERROR, or an HTTP error code.
To use the HTTP POST method, pass both in and out values to json_call. For the GET method, pass a NULL to in. For the PUT method, pass a NULL to out. For the DELETE method, pass both NULL to in and out.
Besides json_call, there are other JSON API functions:
int json_call(soap *ctx, const char *URL, value *in, value *out) makes a POST, GET, PUT, DELETE call, returns SOAP_OK or error code, including HTTP error codes. POST method: pass both in and out. GET method: pass a NULL to in. PUT method: pass a NULL to out. DELETE method: pass both NULL to in and out. SOAP_OK is returned for POST and GET methods upon success. An HTTP status code of 200 (OK) or 202 (Accepted) is returned for PUT and DELETE methods upon success.int json_write(soap *ctx, const value *v) writes JSON value to current file, socket, or stream. Returns SOAP_OK or error. Set file/socket file descriptor to write to with ctx->sendfd = fd (1 by default). In C++, set output stream with ctx->os = ostream to write to.int json_read(soap *ctx, value *v) reads JSON value from current file, socket, or stream. Returns SOAP_OK or error. Set file/socket file descriptor with ctx->recvfd = fd to read from (0 by default). In C++, set input stream with ctx->is = istream.The are two other lower-level functions json_send and json_recv that are similar to json_write and json_read but do not initialize the sending and receiving operations and do not flush after the sending and receiving operations.
To implement a JSON REST server for CGI (e.g. install in cgi-bin):
The above server works with CGI, which is rather slow and stateless. A stand-alone JSON REST server is recommended. You can also use the Apache and IIS plugins for gSOAP to deploy JSON REST services. See the documentation.
Note that we use json_send_fault() instead of soap_send_fault() when an internal error occurred, since we want the error to be reported in JSON format as per Google JSON Style Guide. For application-specific errors, we use json_send_error() as follows:
You can specify an HTTP error code such as 400 in this case, which means that a HTTP 400 Bad Request is returned to the client.
The json_send_error() function is a convenient shortcut to return an error message with an HTTP error code. To return a JSON response with a HTTP error code use the following:
The code for a stand-alone server is the same, except that we call soap_bind() and soap_accept() to serve requests on a port. Here is a simple iterative server serving requests on port 8080:
Note that SOAP_ENC_PLAIN should be used with CGI, since we are reading from a non-HTTP source with CGI. We do not use this flag with gSOAP stand-alone servers. Iterative stand-alone services are not performant and may block requests. We recommend stand-alone multi-threaded services.
Compile and link your code together with soapC.cpp (generated with soapcpp2 -CSL xml-rpc.h), xml-rpc.cpp, json.cpp, and stdsoap2.cpp.
For C++ client and server examples, please see the gSOAP package content gsoap/samples/xml-rpc-json:
json-currentTime.cpp: JSON REST C++ clientjson-currentTimeServer.cpp: JSON REST C++ server (CGI and multi-threaded stand-alone)The presentation in this section concerned stand-alone JSON REST services. To combine SOAP/XML with JSON REST services, see Serving JSON and SOAP requests on the same server port for details.
Note that we only have a queue of one with soap_bind(ctx, NULL, 8080, 1) which rejects multiple requests. Enlarge the queue as you wish, but beware that larger queues can lead to server access problems. Also set appropriate timeouts and message length limits, see the [tutorials](https://www.genivia.com/tutorials.html#How_to_harden_your_application's_robustness_with_timeouts_and_error_handlers)
The JSON-RPC 1.0 specification (the "original version") adds method, parameter and id fields to the request message:
where:
method is a string with the name of the method to be invoked.params is an array of objects to be passed as parameters to the defined method.id is a value of any type, which is used to match the response with the request that it is replying to.A response message has a result field, an error field, and an id:
where:
result is the data returned by the invoked method. If an error occurred while invoking the method, this value must be null.error is a specified error code if there was an error invoking the method, otherwise null.id is the id of the request it is responding to.The JSON-RPC 2.0 specification makes all 1.0 fields REQUIRED, except for error which MUST NOT be present if there was no error triggered during invocation. The 2.0 specification adds a jsonrpc field in the request message:
and also adds the jsonrpc field to the response message:
The C++ operations are straightforward to conform to the JSON-RPC 1.0 or 2.0 specifications. The example JSON-RPC 2.0 request message shown above is created by the following code that uses json_call() to invoke a JSON-RPC service:
For HTTPS use an https endpoint URL. You can control the HTTPS context as explained in the tutorials.
The server-side creates response messages similar to the example shown above. To implement a C++ JSON-RPC and JSON REST server, please see the example json-currentTimeServer.cpp located in gsoap/samples/xml-rpc-json in the gSOAP package.
A JSON value represented by a value may contain raw JSON data as a string to serialize literally in the output. Deserializing JSON into a JSON value never populates this string, so this feature is to augment JSON output with embedded raw JSON data only.
To add raw JSON data create a _rawdata object and assign it to a value:
The _rawdata blob can be assigned anywhere where a value is expected, i.e. as an item of an array or as a value property of a JSON object.
To check that a value contains a _rawdata value and to retrieve it as raw data:
If the raw data blob does not contain \0 bytes, then it is simpler to cast the value to a string:
A C++ namespace is preferred to separate JSON types and operations from other project-related types and operations. This allows you to cleanly compile the JSON API files together with other gSOAP XML data binding files.
To put all JSON (and the internal XML-RPC) types and operations in a json C++ namespace, execute the following commands:
soapcpp2 -qjson -CSL xml-rpc.h soapcpp2 -penv -CSL env.h
where env.h is an empty file. This generates jsonStub.h and jsonH.h and two more files jsonC.cpp and envC.cpp to compile with xml-rpc.cpp, json.cpp, and stdsoap2.cpp.
When combining JSON with a wsdl2h-generated header file that declares an XML data binding interface, use this header file instead of an empty env.h. Use soapcpp2 to generate the data binding and client/server code as usual (without option -penv).
Compile the source files together with xml-rpc.cpp and json.cpp and set the macro -DJSON_NAMESPACE, for example:
c++ -DJSON_NAMESPACE xml-rpc.cpp json.cpp jsonC.cpp envC.cpp stdsoap2.cpp ...
To enable OpenSSL for HTTPS also use -DWITH_OPENSSL to compile. Then link with -lssl and -lcrypto.
Your project should now use the json namespace with the value type, for example:
With the release of gSOAP 2.8.26, the XML-RPC and JSON C APIs have been greatly improved. The material in this section pertains to gSOAP 2.8.26 and later.
The new C API for XML-RPC and JSON makes it much easier to populate and retrieve data, but not as simple and easy as the C++ API.
The following files define XML-RPC operations and data types:
xml-rpc.c: XML-RPC and JSON C API functions to inspect and manipulate dataxml-rpc.h: XML-RPC data binding as a gSOAP .h file for soapcpp2 (do not #include this file in your project builds)In addition to the files above, for JSON we also need the following files:
json.h: JSON C API and JSON serializationjson.c: JSON C API and JSON serializationThe gSOAP header file xml-rpc.h defines all XML-RPC and JSON types and the C API functions to create XML-RPC and JSON data for REST messages.
A note about the following auto-generated files: soapH.h, soapStub.h and soapC.c: these are required for XML-RPC and JSON. To auto-generate these files, execute:
soapcpp2 -c -CSL xml-rpc.h
Then compile and link the .c files listed above for XML-RPC and JSON with the auto-generated soapC.c and stdsoap2.c:
cc -I../.. -o myapp myapp.c json.c xml-rpc.c soapC.c ../../stdsoap2.c
Instead of stdsoap2.c you can link libgsoap.a with -lgsoap, when installed by the gSOAP package.
To enable OpenSSL for HTTPS compile with -DWITH_OPENSSL and link -lssl, and -lcrypto:
cc -DWITH_OPENSSL -I../.. -o myapp myapp.c json.c xml-rpc.c soapC.c ../../stdsoap2.c -lssl -lcrypto
For OpenSSL support, instead of stdsoap2.c you can link libgsoapssl.a with -lgsoapssl, when installed by the gSOAP package.
Because XML namespaces are not used, we can either use -DWITH_NONAMESPACES to compile stdsoap2.c without complaining about a missing global Namespace, or we can define an empty namespaces table somewhere in our code:
An XML-RPC/JSON data value is created in C as follows, which requires a context ctx with the engine state (the soap struct). The context manages the memory that is internally allocated to hold values.
Note that soapH.h is an auto-generated file (see previous section). This file needs to be generated only once and for all. It also references stdsoap2.h and the auto-generated soapStub.h. Compile and link your code with stdsoap2.cpp and the auto-generated soapC.cpp XML-RPC serializers. Also compile and link xml-rpc.cpp. For JSON, compile and link json.cpp.
With the C API, allocating a context and values on the heap may return NULL when your system runs out of memory. On most systems this is unlikely to happen, but to safeguard your code check for NULL returns as follows:
Also, when enlarging structs and arrays by indexing them beyond their current content, the enlargement may fail and a NULL pointer is returned.
You can use wide strings with Unicode stored in UTF-8-formattted 8-bit char strings. For compatibility with XML-RPC serialization of UTF-8-encoded strings, we MUST use the SOAP_C_UTFSTRING flag to initialize the context with soap_new1(SOAP_C_UTFSTRING).
The code shown above creates an empty value v. Values can be assigned any one of the following data types:
The functions above return a pointer to a specific type of value and this value can be assigned as shown above but also read. So we use these functions also to retrieve data, for example after receiving XML-RPC or JSON data.
We can combine this syntax in many possible ways to create arrays of arrays, arrays of structs, and so on. For example:
This creates a singleton array containing an object with two members: name set to "bob" and toys set to an array containing "ball" and "furby". In JSON format this is represented as:
[ { "name": "bob", "toys": ["ball", "furby"] } ]
^ ^ ^ ^
| | | |
an array_/ | | |
of 1 struct_/ | |
with 2 members_/______________/
Let's see what happens when we assign a variable the value of another.
The JSON C API uses the reference model for variables, meaning that values are shared when assigning a target variable the value of another variable. The variable values are shared until one or the other variables is assigned a different type of value. We illustrate the effect below:
This prints x = 2 and y = 2 and x = 3.1 and y = 2.
You can make a copy of an atomic value with one of the Type_of() functions. The following code illustrates how:
This prints x = 2 and y = 1.
You can also make deep copies of values by using the auto-generated soap_dup_value function in soapC.c:
This prints a[0] = 2 and b[0] = 1.
To auto-generate soap_dup_value, use option -Ec with soapcpp2:
soapcpp2 -c -Ec -CSL xml-rpc.h
When receiving a value in XML-RPC or JSON, we generally want to check its type to obtain its value. To check the type of a value, we use is_Type functions:
When working with JSON data, do not use is_double() but is_number(). JSON data does not differentiate between integers and floats. However, gSOAP makes sure that 64 bit integer values are accurately represented in JSON and decoded without loss from JSON. That is, when receiving an integer that you checked with is_int() you can then safely retrieve the value with int_of(), for example int64_t n = *int_of(v).
The following functions can be used with arrays and structs (JSON objects):
When accessing structs (JSON objects) with value_at, make sure to use existing member field names only. A new member fieldname-value pair is dynamically added to the structure to accomodate the new entry for the field.
Also arrays are extended with nth_value to accommodate the indexed array element.
A negative array index indexes elements from the end of the array, with index -1 accessing the array's last value.
Use set_size to change array size or set arrays to zero length. Use negative size with set_size to remove elements from the end.
For example, let's take the value v that was assigned the array shown above. We have the following properties of this value:
Considering that the code verbosity quickly increases when accessing deeper levels of your structures, you are probably inclined to define your own macros to create and access deep data more conveniently, such as:
To iterate over array and struct values, we use a loop over nth_value and nth_member as follows:
To access base64 binary raw data of a value v, we use the following code:
XML-RPC parameter lists are similar to arrays and its values are indexed. We can also loop over response parameters after an XML-RPC REST call:
We should note that JSON REST does not require parameter types, for example:
All dynamically allocated memory that is internally used to store data is deallocated with:
Additional examples are located in gsoap/samples/xml-rpc-json:
json-currentTime.c JSON REST C clientjson-currentTimeServer.c JSON REST C server (CGI and multi-threaded stand-alone)json-GitHub.c: JSON C client for GitHub API v3xml-rpc-currentTime.c XML-RPC C clientxml-rpc-weblogs.c XML-RPC C clientAn XML-RPC method call in C with the new XML-RPC C API:
The following example shows how to traverse the node graph to display a value:
Compile and link your code together with soapC.c (generated), xml-rpc.c, and stdsoap2.c.
To write values in JSON format or parse JSON data, we use the json.h and json.c JSON C API. It is also possible to send and receive JSON data over HTTP (JSON REST).
Reading and writing XML from/to files, streams and string buffers is done via the managing context by setting one of the following context members that control IO sources and sinks:
For example, to read and write JSON data from/to a file descriptor:
To force reading and writing JSON in ISO 8859-1 format, use the SOAP_ENC_LATIN flag to initialize the context (not recommended).
Optionally use SOAP_XML_INDENT to indent XML and JSON output.
To parse JSON values from a file or from any other non-HTTP source, it is recommended to set the SOAP_ENC_PLAIN context flag to prevent the parser from attempting to read a MIME or HTTP headers (HTTP headers are required with JSON-RPC):
You can also read and write JSON data from/to NUL-terminated strings:
Compile and link your code together with soapC.c (generated), xml-rpc.c, json.c, and stdsoap2.c.
You can also convert XML-RPC data to/from JSON and populate XML-RPC from JSON data. The XML-RPC parsing and sending functions are soap_read_value and soap_write_value, respectively.
The JSON protocol has fewer data types than XML-RPC, so type information can be lost when serializing to JSON:
Strings are stored and exchanged in UTF-8 format in 8-bit strings (i.e. char* strings) with the SOAP_C_UTFSTRING flag. Wide strings (i.e. wchar_t* strings) are converted to UTF-8.
To read JSON from a string and write JSON to a string, we suggest to use gSOAP 2.8.28 or later. With these newer versions you can set the contex input string ctx->is to the string to parse (reset to NULL afterwards) as follows:
You can set the context output string pointer ctx->os to point to the const char* string that you want to be set. This string will point to the JSON data created by the engine and managed by the context as follows:
For older versions prior to 2.8.28, the gSOAP engine's IO frecv callback function can be used as follows to parse JSON from a string buffer:
For older versions prior to 2.8.28, the gSOAP engine IO fsend callback function can be used to write JSON to strings as follows:
To use JSON REST on the client side, we use json_call:
The json_call function takes a context, an endpoint URL (with query string parameters as needed), and optional in and out values to send and receive, respectively. The function returns SOAP_OK (zero) for success or EOF, SOAP_SYNTAX_ERROR, or an HTTP error code.
To use the JSON REST POST method, pass both in and out values to json_call. For the GET method, pass a NULL to in. For the PUT method, pass a NULL to out. For the DELETE method, pass both NULL to in and out.
Besides json_call, there are other JSON API functions:
int json_call(struct soap *ctx, const char *URL, struct value *in, struct value *out) makes a POST, GET, PUT, DELETE call, returns SOAP_OK or error code, including HTTP error codes. POST method: pass both in and out. GET method: pass a NULL to in. PUT method: pass a NULL to out. DELETE method: pass both NULL to in and out. SOAP_OK is returned for POST and GET methods upon success. An HTTP status code of 200 (OK) or 202 (Accepted) is returned for PUT and DELETE methods upon success.int json_write(struct soap *ctx, const struct value *v) Writes JSON value to current file or socket. Returns SOAP_OK or error. Set current file/socket file descriptor with ctx->sendfd = fd. Or save JSON to a string by setting ctx->os = &cs with const char *cs a string pointer that will be set to a NUL-terminated string when the write completed.int json_read(struct soap *ctx, struct value *v) Reads JSON value from current file or socket. Returns SOAP_OK or error. Set current file/socket file descriptor with ctx->recvfd = fd. Or read from string by setting ctx->is = cs to a const char *cs NUL-terminated string.The are two other lower-level functions json_send and json_recv that are similar to json_write and json_read but do not initialize the sending and receiving operations and do not flush after the sending and receiving operations.
Compile and link your code together with soapC.c (generated), xml-rpc.c, json.c, and stdsoap2.c.
To implement a JSON REST server for CGI (e.g. install in cgi-bin):
The above server works with CGI, which is rather slow and stateless. A stand-alone JSON REST server is recommended. You can also use the Apache and IIS plugins for gSOAP to deploy JSON REST services. See the documentation.
Note that we use json_send_fault() instead of soap_send_fault() when an internal error occurred, since we want the error to be reported in JSON format as per Google JSON Style Guide. For application-specific errors, we use json_send_error() as follows:
You can specify an HTTP error code such as 400 in this case, which means that a HTTP 400 Bad Request is returned to the client.
The json_send_error() function is a convenient shortcut to return an error message with an HTTP error code. To return a JSON response with a HTTP error code use the following:
The code for a stand-alone server is the same, except that we call soap_bind() and soap_accept() to serve requests on a port. Here is a simple iterative server serving requests on port 8080:
Note that SOAP_ENC_PLAIN should be used with CGI, since we are reading from a non-HTTP source with CGI. Do not use this flag with gSOAP stand-alone servers. Iterative stand-alone services are not performant and may block requests. We recommend stand-alone multi-threaded services.
Compile and link your code together with soapC.c (generated with soapcpp2 -c -CSL xml-rpc.h), xml-rpc.c, json.c, and stdsoap2.c.
For client and server examples, please see the gSOAP package content in gsoap/samples/xml-rpc-json:
json-currentTime.c JSON REST C clientjson-currentTimeServer.c JSON REST C server (CGI and multi-threaded stand-alone)The presentation in this section concerned stand-alone JSON REST services. To combine SOAP/XML with JSON REST services, see Serving JSON and SOAP requests on the same server port for details.
Note that we only have a queue of one with soap_bind(ctx, NULL, 8080, 1) which rejects multiple requests. Enlarge the queue as you wish, but beware that larger queues can lead to server access problems. Also set appropriate timeouts and message length limits, see the [tutorials](https://www.genivia.com/tutorials.html#How_to_harden_your_application's_robustness_with_timeouts_and_error_handlers)
The JSON-RPC 1.0 specification (the "original version") adds method, parameter and id fields to the request message:
where:
method is a string with the name of the method to be invoked.params is an array of objects to be passed as parameters to the defined method.id is a value of any type, which is used to match the response with the request that it is replying to.A response message has a result field, an error field, and an id:
where:
result is the data returned by the invoked method. If an error occurred while invoking the method, this value must be null.error is a specified error code if there was an error invoking the method, otherwise null.id is the id of the request it is responding to.The JSON-RPC 2.0 specification makes all 1.0 fields REQUIRED, except for error which MUST NOT be present if there was no error triggered during invocation. The 2.0 specification adds a jsonrpc field in the request message:
and also adds the jsonrpc field to the response message:
The C operations are straightforward to conform to the JSON-RPC 1.0 or 2.0 specifications. The example JSON-RPC 2.0 request message shown above is created by the following code that uses json_call() to invoke a JSON-RPC service:
For HTTPS use an https endpoint URL. You can control the HTTPS context as explained in the tutorials.
The server-side creates response messages similar to the example shown above. To implement a C JSON-RPC and JSON REST server, please see the example json-currentTimeServer.c located in gsoap/samples/xml-rpc-json in the gSOAP package.
A JSON value represented by a value may contain raw JSON data as a string to serialize literally in the output. Deserializing JSON into a JSON value never populates this string, so this feature is to augment JSON output with embedded raw JSON data only.
To add raw JSON data create a _rawdata structure and assign it to a value:
The _rawdata blob can be assigned anywhere where a value is expected, i.e. as an item of an array or as a value property of a JSON object.
To check that a value contains a _rawdata value and to retrieve it as raw data:
To use JSON (and XML-RPC) with other gSOAP XML data binding code requires a few simple steps to ensure that your project compiles cleanly.
For C++, arguably the best option is to Moving JSON types and operations into a C++ namespace .
We present three methods that you can follow. These methods follow different strategies to compile a combined set of files with JSON (and XML-RPC) types and operations with other files with XML data binding types and operations:
Before processing a gSOAP XML data binding header file with soapcpp2, add #import "xml-rpc.h" to this header file to include XML-RPC and JSON data types. Then compile the generated files as usual together with jcon.c (or json.cpp for C++) and xml-rpc.c (or xml-rpc.cpp for C++). Also #include "json.h" in your code to use the JSON API.
This is the simplest method. When using wsdl2h, you can automate this method by adding the following three lines to typemap.dat:
[ #import "xml-rpc.h" ]
This automatically imports the JSON/XML-RPC types and operations into the XML data binding code. You will still need to compile your code together with jcon.c (or json.cpp for C++) and xml-rpc.c (or xml-rpc.cpp for C++).
Use soapcpp2 option -qjson to generate and compile the JSON (and XML-RPC) API code to combine with your other XML data binding code generated with soapcpp2:
soapcpp2 -qjson -CSL xml-rpc.h
This generates jsonStub.h, jsonH.h, and jsonC.cpp.
Compile the files jsonC.cpp, xml-rpc.cpp, and json.cpp with option -DJSON_NAMESPACE and your other source code files, such as those generated by soapcpp2 for your other .h file:
c++ -DJSON_NAMESPACE json.cpp jsonC.cpp xml-rpc.cpp ...
Make sure to use #include "json.h" in your code.
The JSON C++ API is in the json C++ namespace. See also Moving JSON types and operations into a C++ namespace .
Use soapcpp2 option -pjson to generate and compile the JSON (and XML-RPC) API code to combine with your other XML data binding code generated with soapcpp2:
soapcpp2 -c -pjson -CSL xml-rpc.h
This generates jsonStub.h, jsonH.h, and jsonC.c.
Compile the files jsonC.c, xml-rpc.c, and json.c with option -DJSON_NAMESPACE and your other source code files, such as soapClientLib.c generated by soapcpp2 with option -C for your other .h file:
cc -DJSON_NAMESPACE json.c jsonC.c xml-rpc.c soapClientLib.c stdsoap2.c ...
or the soapServerLib.c file generated by soapcpp2 with option -S:
cc -DJSON_NAMESPACE json.c jsonC.c xml-rpc.c soapServerLib.c stdsoap2.c ...
Make sure to use #include "json.h" in your code.
This method also works in C++, but it is recommended to use the second method for C++ applications.
SOAP requests are served using the usual soap_serve() call generated by soapcpp2 given an interface header file with SOAP/XML Web service definitions.
We can also serve JSON requests on the same port by using the gSOAP HTTP POST plugin. This plugin serves non-SOAP requests when soap_serve() is called by capturing the HTTP content type of the request and also handles PUT, PATCH and DELETE requests. The httpget plugin is located in gsoap/plugin/httppost.h and gsoap/plugin/httppost.c.
The plugin captures POST requests that have a content type matching a content type entry specified in a table of POST, PUT, PATCH and DELETE handlers. Each entry in this table specifies a content type of a POST request with the function to invoke that will handle it. We can also specify generic POST, PUT, PATCH and DELETE request handlers in this table:
A * can be used as a wildcard to match any characters and - is a wildcard that matches one character. For example, "text/*" matches any text media type.
To register the plugin (see also the gSOAP manual):
The handlers in the example my_handlers table given above are used by the plugin to dispatch the request. If a non-SOAP or non-POST request is made, the handler in the table that matches the HTTP content type of the request is invoked. Also generic POST, PUT, PATCH and DELETE handlers can be optionally specified.
A handler in the my_handlers table is a function that takes the context and returns SOAP_OK or an error code. Here is an example json_handler in C:
Note that we use json_send_fault() instead of soap_send_fault() when an internal error occurred, since we want the error to be reported in JSON format as per Google JSON Style Guide. For application-specific errors, we use json_send_error() as follows:
You can specify an HTTP error code such as 400 in this case, which means that a HTTP 400 Bad Request is returned to the client.
The json_send_error() function is a convenient shortcut to return an error message with an HTTP error code. To return a JSON response with a HTTP error code use the following:
The soap_closesock() call only closes the connection when it shoud not be kept alive. This function is also called automatically after the handler returns. The function returns the soap:error value in order to pass an error code along the chain of calls. There is no harm in calling this function more than once.
A generic_POST_handler should be similar to the above. The HTTP content type of the request is stored in the http_content string variable of the context.
A generic_PUT_handler and generic_PATCH_handler should not return a response message but should call soap_send_empty_response() instead. Likewise, these handlers should return a HTTP status code instead of calling json_send_error() since the HTTP body should be empty:
The soap_tag_cmp() function is similar to strcmp() but it is case insensitive and supports * (any number of characters) and - (any single character) wildcards.
To compile your server application that serves JSON and SOAP requests, see Compiling XML-RPC/JSON together with gSOAP SOAP services and XML .
The httppost plugin sets the soap::fput, soap::fpatch and soap::fdel callbacks to serve HTTP PUT, PATCH and DELETE requests, respectively. The HTTP POST requests are handled differently, via soap_serve() that invokes the soap::fform callback that points to the handler. This callback is set by the httppost plugin upon receiving a HTTP POST request that matches the key in the table, i.e. "POST" always matches and "application/json" only matches when the HTTP Content-Type is application/json. When a SOAPAction header is present in the HTTP POST request, then the POST handler is never invoked to allow soap_serve() to process the request.
generic_POST_handler, when specified with a "POST" key entry in the table, takes priority over soap_serve() if no SOAPAction HTTP header is included in the message. This means that SOAP/XML messages without a SOAPAction header will not be processed by soap_serve()!The floating point format used to output values in XML-RPC and JSON is by default ".17lG' to ensure accuracy up to the last digit. The format can be set as follows:
JSON has no binary type to transmit binary data. Sending binary data in JSON strings as text is not recommended, due to NULs and problems with Unicode/UTF-8 sequences.
Base64 is a common encoding format for binary data. A JSON string with base64 content is our recommended option.
To populate JSON data with base64-encoded binary content, you can simply create and assign a _base64 value as described earlier (e.g. by casting a _base64 structure to a value in C++). Receiving base64-encoded content with JSON is not possible, because the necessary type information is lost in transit. The base64 content will arrive at the receiver simply as a string with base64 content.
You can explicitly decode the base64 string back to binary as shown here for C++:
And for C:
To populate JSON data with ISO 8601 date time content, you can simply assign a ULONG64 value cast from a time_t value as described earlier. Receiving ISO 8601 date time content with JSON is not possible, because the necessary type information is lost in transit. The content will arrive at the receiver simply as a string with a date and time.
You can explicitly convert a string with an ISO 8601 date time to a time_t value as shown here for C++:
And for C:
The disable UTC time zone Z in the dateTime string, use -DWITH_NOZONE to compile stdsoap2.c (for C) or stdsoap2.cpp (for C++).
The JSON parser follows the published JSON "standards" but is a bit more forgiving, meaning that it parses the following extensions:
NaN, +Inf, -Inf as floating point values.0xHHHH.SOAP_ENC_PLAIN flag to initialize the context, otherwise files containing just the JSON values true, false, and null are not parsed.Copyright (c) 2017, Robert van Engelen, Genivia Inc. All rights reserved.