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.