XML-RPC: remote procedure calls in XML format
Calling functions via remote access on remote computers in the network or in distributed systems (i.e. a collection of independent computers) has been common practice for decades. The basic idea for the foundational technology RPC (remote procedure calls) was established back in 1976 by James E. White in RFC 707, which makes the principle older than the World Wide Web.
Google developed the gRPC framework in 2015 to enable RPC to meet requirements of modern computer system structures.
XML-RPC is one of the most popular solutions allowing users to employ handy RPC requests for their own needs. This solution executes calls using the HTTP(S) protocol and Extensible Markup Language (XML). So, what exactly is this specification, when is it used, and how does it work?
What is XML-RPC?
XML-RPC (short for Extensible Markup Language remote procedure call) is a protocol specification for executing RPC calls (remote calls in computer networks) using the stateless network protocol HTTP and the markup language XML, which gives it part of its name. While HTTP controls data transfer, XML is used to display this data. When the XML-RPC standard was defined, much emphasis was placed on easy implementation in a variety of programming languages and system platforms.
The XML-RPC specification only supports the unsecured HTTP protocol for data transfer. But there are widely used and accepted versions of the standard that support the more secure HTTPS protocol, which also uses SSL/TLS encryption.
XML-RPC was developed in 1998 through a close collaboration between Microsoft and Dave Winer, the lead software developer and founder of UserLand Software. Microsoft saw great potential in the new standard for boosting its own B2B relations. By continuously adding new functions, XML-RPC has established itself as an interface protocol for web services. The refined form of XML-RPC became known as SOAP (Simple Object Access Protocol).
How does XML-RPC work?
Clients who want to use XML-RPC use the transfer protocol HTTP – more precisely the HTTP request method POST. After receiving the HTTP request, the server analyzes the XML document contained in the body of the request. It then generates the parameters for the desired function from its contents and executes them. The server packs the result back into an XML document which is transferred back to the client in an HTTP response. XML-RPC supports the following data types for the transfer of parameters or in the response the client receives:
|Data type||Tag example||Description|
|array||<array><data>…</data></array>||A list that can contain multiple values or data types|
|base64||<base64>SGFsbG8gV2VsdA==</base64>||Base64-encoded binary data|
|boolean||<boolean>1</boolean>||Boolean variable (true = 1 vs. false = 0)|
|dateTime.iso8601||<dateTime.iso8601>20200414T16:23:55</dateTime.iso8601>||Date and time in ISO 8601 format|
|double||<double>-0.32653</double>||Double precision floating point number (64-bit)|
|integer||<int>32</int> or <i4>32</i4>||Integer (whole number)|
|string||<string>Hello world!</string>||String of characters; can contain zero bytes|
|struct||<struct><data>…</data></struct>||Set of key-value pairs (keys in this case are character strings and values can be any type)|
If you need to combine multiple values or data types, XML-RPC syntax offers two options: “array” and “struct”. The first option allows you to list the desired data consecutively in any order. The “struct” option is used to transfer predefined key-value pairs to the server, as shown in the example below:
<struct> <member> <name>entry 1</name> <value><int>1</int></value> </member> <member> <name>entry 2</name> <value><int>2</int></value> </member> </struct>
Some programming languages like Java which have XML-RPC implementations also allow you to enter null values. To do so, you must always use the data type “nil” in XML documents. However, this data type is not officially part of the XML-RPC specification and is not supported by all servers.
When is XML-RPC used?
XML-RPC is no longer very important in modern network communication. After its publication in 1998, this transfer format quickly proved to be too inflexible. This is partly due to its limited extensibility and the fact that it cannot transfer its own XML structures. As a result, a significant amount of work was required for conversion which rendered finding a new solution more or less vital. This was quickly developed in the form of the aforementioned SOAP (also developed by Winer’s team in collaboration with Microsoft).
Nevertheless, there are still web applications today that use the XML-RPC interface (e.g. for enabling simple data transfer between external services). For example, the German Federal Central Tax Office (the Bundeszentralamt für Steuern) provides an XML-RPC interface for performing automated checks of foreign VAT IDs (as of 2019 via HTTPS requests). Content management systems such as WordPress often use an XML-RPC interface for exchanging data with other web services. In addition, the transfer format is the basis for the pingback technique which has been an important link-building tool for bloggers for many years. You can learn more about this by checking out the article “What are pingbacks and trackbacks?”.
Example of a simple server request via XML-RPC
Lastly, let us take a look at a simple example illustrating client-server communication via an XML-RPC interface. The client’s HTTP request looks like this:
<?xml version="1.0"?> <methodCall> <methodName>statustest</methodName> <params> <param> <value><i4>10</i4></value> </param> </params> </methodCall>
In this example, the function “statustest” is called in the container “methodCall” which in turn is defined in the container “methodName”. The function provides the integer value “10” as the parameter.
The following is what a possible server response to this “statustest” could look like:
<?xml version="1.0"?> <methodResponse> <params> <param> <value><string>Status: OK</string></value> </param> </params> </methodResponse>
The server’s simple response in this example is “Status: OK”.