While REST and JSON are in vogue for APIs, there are still plenty of APIs out there using the (not-so) venerable XML-RPC specification, which dates all the way back to 1999. Yes, this is a technology that may be older than your youngest co-workers in the very near future!
If you’re calling an XML-RPC API, you’ll probably using a library to wrap the actual interface, and given the age of the technology, you might be using PHP. For example, WordPress exposes an XML-RPC API, and contains a XML-RPC library, but there are many options available, across many different languages. You might not even be aware that the interface is using XML-RPC, as the library creates the requests and parses the responses for you.
XML-RPC APIs, as you might have guessed, use XML for both queries and responses, a bit like SOAP, but in a lighter-weight fashion. It doesn’t use HTTP’s semantics for methods like REST – every call you make is a POST, as you need to send XML. What’s more, every response you get back will be an HTTP 200 response.
In PHP you might set up a call, something like this:
// 1. Create client $client = new xmlrpc_client('http://example.com/xmlrpc.php', true); // 2. Prepare the query $args = array('page' => 1, 'message' => 'Hello World'); // 3. Execute the query $resp = $client->call('someMethod', $args);
There’s a semantic difference between REST and XML-RPC – in REST, you transfer “resource representations” whereas XML-RPC you call methods – RPC stands for Remote Procedure Call.
Do what’s happening inside the library? It creates a curl request, POSTing XML to the URL. The endpoint specified may handle several different methods, so the method name is part of the XML format.
The XML for our code above looks something like this:
<?xml version="1.0" ?> <methodCall> <methodName>someMethod</methodName> <params> <struct> <member> <name>page</name> <value><int>1</int></value> </member> <member> <name>message</name> <value><string>Hello World</string></value> </member> </struct> </params> </methodCall>
The methodCall root node contains a methodName – which is what procedure you want to run, and a params node contains any parameters that need to be passed to that procedure. Complex parameters can be built up of struct nodes, which each have a name and a value. There’s typing information in the XML for the values, as otherwise that information would be lost from the XML. Helpfully, unlike JSON, there’s an explicit date/time format and a base64 binary encoded data format.
Then, set your content and expected response types to XML. Enter the XML in the content entry area at the bottom of the page:
The response you get back is similarly formatted in XML. If there’s a problem, the response will contain a fault node in the XML, even though it returns as part of an HTTP 200 OK response.
<?xml version="1.0"?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>4</int></value> </member> <member> <name>faultString</name> <value><string>Too many parameters.</string></value> </member> </struct> </value> </fault> </methodResponse>
You can read more about our XML parsing capabilities on our help site. As always, if you have any problems or need any help setting your APIs, don’t hesitate to contact us.