XML-RPC Specification (1999)

I&#x27;ve had the great misfortune to be writing code against an XML-RPC service recently. It&#x27;s really a miserable design, even compared to contemporaries like Sun RPC.<p>* Incredibly verbose. Even a trivial array value like [1, 2, 3] encodes to over a hundred bytes. I&#x27;m convinced the author was not aware of attributes, or for some reason held a grudge against them.<p>* There&#x27;s only like five primitive types, so implementations that want to transmit wild and unusual values such as <i>64-bit integers</i> need to define their own ad-hoc extensions.<p>* It&#x27;s written in XML but there&#x27;s no namespace, and implementations may or may not use namespaces for their extensions. Is an int64 represented as `i8` or `{<a href="http:&#x2F;&#x2F;ws.apache.org&#x2F;xmlrpc&#x2F;namespaces&#x2F;extensions}i8" rel="nofollow">http:&#x2F;&#x2F;ws.apache.org&#x2F;xmlrpc&#x2F;namespaces&#x2F;extensions}i8</a>`? Depends on which library you&#x27;re talking to!<p>* There&#x27;s a native &quot;date&#x2F;time&quot; type, but the syntax is unspecified other than being ISO8601-ish. Don&#x27;t even get me started on timezones, which will probably be in the local time of the server, but might be in UTC or BST or who knows what.<p>* The XML-RPC spec claims that &lt;string&gt; elements can be used to transmit any character except &#x27;&lt;&#x27; and &#x27;&amp;&#x27;, including binary data, <i>including NUL</i>. I want you to imagine what that looks like on the decoding end. Your XML parser is just humming along, decoding UTF-8 and lexing some tags, and all the sudden it comes across a <i>big blob of fucking binary data</i> in the middle of the document. Why was this allowed when the spec also defines a &lt;base64&gt; element??<p>The XML-RPC spec ought to come with a Surgeon General&#x27;s warning that reading it might give you brain worms.

Still using JSON-RPC 1.0 over HTTP here:<p><pre><code> - specs so simple it&#x27;s incredibly easy to implement client and server in most languages - good enough for most use case, supports whatever that can be expressed in JSON - easy enough to inspect, it&#x27;s just JSON - not too heavy compared to XML-RPC - as performant as your JSON serializer&#x2F;deserializer - None of the ReSTish philosophical questionings - understood by developers of any generation: call methods with parameters</code></pre>

I wrote a post about this thread. I am the author of the XML-RPC spec and co-designer of the format.<p><a href="http:&#x2F;&#x2F;scripting.com&#x2F;2022&#x2F;07&#x2F;16.html#a172934" rel="nofollow">http:&#x2F;&#x2F;scripting.com&#x2F;2022&#x2F;07&#x2F;16.html#a172934</a>

20 years ago or so I wrote a LiveJournal client that used the XML-RPC interface. At the time the choices were that or an older custom text interface. The XML-RPC interface was more understandable to a very beginning developer and even then there were libraries I could use in Visual Basic that took care of all the hard parts. The worst part was that not everything was available via the XML interface so you still had to drop back to the old text interface for some things.<p>While yeah it’s pretty dated by modern standards at the time it was a revelation that you could build standard-based APIs that anyone could use with a simple library and without having to write a TON of custom code.<p>And regardless, it was far easier to implement than SOAP, which was just a mistake unless you are fully immersed in the Java ecosystem.

I worked with Edd Dumbill[1] to bring HTTPS and certificate support to the PHP XML-RPC bindings. It was one of my very first open source contributions and interactions, and it was super empowering. I was running the tech at Voxel.net at the time, an early web hosting provider to many open source projects. We were using XML-RPC to write the beginnings of Ubersmith[2], which was our billing, hosting, and support management platform.<p>Later, those bindings made it into very early Drupal core[3] and onto thousands of websites. In this era, you could make desktop apps talk to websites using an XML-RPC gateway — for content management or many other tasks.<p>Yes, XML and related tech is fairly horrible, but context is everything.<p>If you were running servers, there was enormous pressure to use Microsoft.<p>If you were by chance running open source (LAMP stack), making applications work together was a challenge. Interoperability was not the norm, despite a pretty rich internet. Formats and standards were the problem.<p>You would email code patches around. There was no GitHub, and SourceForge was only starting to gain traction.<p>If were using open source version control in this era, you were likely on CVS, which was an &quot;improvement&quot; over RCS, but still nothing like the promised future tech of Subversion, which wasn&#x27;t text-backed. Text-backed! Versions of files were concatenated, and instead of force pushing, you opened this concatenation abomination in a text editor to hack the repo history (if you were a bad, bad person, but needed to get the job done).<p>As mentioned many other places in this thread, if you were doing open source interop, the heavyweight option was SOAP. XML-RPC was as much a breath of fresh air as JSON is to XML.<p>Fairly-literal text was bloated, slow, and XML even more so, but it was all pretty cutting edge for the time.<p>[1] <a href="https:&#x2F;&#x2F;www.xml.com&#x2F;pub&#x2F;au&#x2F;11" rel="nofollow">https:&#x2F;&#x2F;www.xml.com&#x2F;pub&#x2F;au&#x2F;11</a><p>[2] <a href="https:&#x2F;&#x2F;ubersmith.com" rel="nofollow">https:&#x2F;&#x2F;ubersmith.com</a><p>[3] <a href="https:&#x2F;&#x2F;git.drupalcode.org&#x2F;project&#x2F;drupal&#x2F;-&#x2F;blob&#x2F;4.0.x&#x2F;includes&#x2F;xmlrpc.inc#L443" rel="nofollow">https:&#x2F;&#x2F;git.drupalcode.org&#x2F;project&#x2F;drupal&#x2F;-&#x2F;blob&#x2F;4.0.x&#x2F;inclu...</a>

Just to repeat what everyone else is saying: it was awful, but a whole lot better than SOAP.<p>I wrote a service to allow BSD servers running Python apps to run SQL queries on a Windows server running Visual FoxPro, and everything at the time said SOAP is what you use for such things. That was overengineering writ large. After a while I replaced it with XML-RPC and life got much easier.<p>If JSON had widely existed at the time, and someone would have shown it to me, they would’ve been my friend for life.

&quot;Fun&quot; Fact: ROS (the &quot;Robot operating system&quot;) has used XML-RPC under the hood for many years. While it&#x27;s finally transitioning away with the move to ROS2, I expect that it will still be in use in this space for many years to come, for better or worse.<p><a href="http:&#x2F;&#x2F;wiki.ros.org&#x2F;ROS&#x2F;Technical%20Overview" rel="nofollow">http:&#x2F;&#x2F;wiki.ros.org&#x2F;ROS&#x2F;Technical%20Overview</a>

Aah xml-rpc; don&#x27;t know why it is found interesting these days but still ..,<p>My thinking is: <i>if</i> you employ a relative high-ceremony meta-language such as XML as service payload format, then you&#x27;ll at least want to use its features to model free yet strictly validated information exchanges (such as ASN-based protocols have been doing). But xml-rpc doesn&#x27;t give you that and imposes param=values logic known from simple URL-encoded invocation forms instead, improving little over those.<p>Then SOAP was introduced as the big unified payload serialization format covering document- and RPC-oriented uses. We all know just how it sucked.<p>But then came the even worse end result&#x2F;eternal September of &quot;REST&quot; APIs - a misuse of HTTP and blatant and painful misappropriation of Fielding&#x27;s concepts, whose proponents used SOAP&#x27;s flaws as an excuse for their anti-engineering practices.

Pretty sure the WordPress API is still XML-RPC. Like many things in tech, it’s a lot more common than you might think, even after three or four “replacement” technologies.

To be honest, I am very fond of XML-RPC. It is a very easy protocol to understand and implement. It is my first choice for my own small personal projects.

I used it just the other day to talk to a Flectra server.

It&#x27;s important we publish things like this so the next generation will know what not to do.

XML: The greatest productivity destroyer of the 20th century.