16 ms·

XML-RPC Specification (1999)

68 points by rdpintqogeogsaa 4y ago

retrocryptid 4y ago
It's important we publish things like this so the next generation will know what not to do.
gusfoo 4y ago
XML: The greatest productivity destroyer of the 20th century.
- pjmlp 4y ago
  Only when developers insist in using stuff like vi to write it by hand.
  - jkmcf 4y ago
    I always expected the great boon of XML to be a proliferation of tools leveraging XSD to provide GUIs for managing the XML files. XML seemed like a great way to manage config files, but even auto-complete wasn't enough IMO. I'm thinking specifically about Apache Jakarta config files. Not sure if any ever existed. Of course, I'm unsure if XSDs were much used outside of big Java shops.
    - pjmlp 4y ago
      They did exist, on the domains where development tools actually get paid for.
tannhaeuser 4y ago
Aah xml-rpc; don't know why it is found interesting these days but still .., My thinking is: if you employ a relative high-ceremony meta-language such as XML as service payload format, then you'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't give you that and imposes param=values logic known from simple URL-encoded invocation forms instead, improving little over those. Then SOAP was introduced as the big unified payload serialization format covering document- and RPC-oriented uses. We all know just how it sucked. But then came the even worse end result/eternal September of "REST" APIs - a misuse of HTTP and blatant and painful misappropriation of Fielding's concepts, whose proponents used SOAP's flaws as an excuse for their anti-engineering practices.
- outofmyshed 4y ago
  If REST APIs are the worst, how does that account for their immense utility and popularity? I wrangled XML-RPC and SOAP back in the day. It was bad enough when you had exactly the same stacks talking to each other. When you had to interop between systems, ie .NET talking to Java, which was half the point of it all, it was a whole new circle of hell.
  - akx 4y ago
    Trying to get Python SOAP stacks to talk to Java/.NET banking services was another thing too. I still get mild PTSD from thinking about XMLsec and XML c14n.
  - Pamar 4y ago
    I have to disagree. I used XML-RPC exactly twice, but it proved to be a quick solution to nasty integration problems and we were very happy with it. Case #1 - we had to implement an interface to book flights on Amadeus (https://amadeus.com/en https://amadeus.com/en). In order to guarantee the caller identity they provided a C library (binaries that you had to link with your stuff) that would generate tokens that you would then add to your own calls to them to guarantee your identity. We were trying to use it from a Solaris machine, and the library would bomb at each call. But their Windows binary module worked fine, so we basically put up an XML-RPC connection between our Solaris hosted main app and a little Windows service which would simply provide the token for us to embed in the subsequent call. (This was the only way we could find to hit our release date in time, and it worked fine for 5 years serving hundred of thousands of calls every year). Case #2 - less "business critical", but still fine: I was on sick leave from the office recovering from minor trauma to my knee and here is what I suggested to a guy trying to use a PERL library as part of non-PERL stack: https://stackoverflow.com/a/2635719/54504 https://stackoverflow.com/a/2635719/54504 (it was part of his final exam for a degree in CS, I provided more assistance outside of StackOverflow and he was very happy with the results).
  - tannhaeuser 4y ago
    Yes SOAP interoperability sucked, no arguing about that. The fact alone that you needed interoperability guidelines (WS-I) on top speaks volumes about W3C's derailed standardization effort - a similar problem is hunting today's OAuth standard btw. But just that SOAP sucks doesn't mean "REST" is ideal. Fallacy of the excluded middle and all.
jmillikin 4y ago
I've had the great misfortune to be writing code against an XML-RPC service recently. It's really a miserable design, even compared to contemporaries like Sun RPC. * Incredibly verbose. Even a trivial array value like [1, 2, 3] encodes to over a hundred bytes. I'm convinced the author was not aware of attributes, or for some reason held a grudge against them. * There's only like five primitive types, so implementations that want to transmit wild and unusual values such as 64-bit integers need to define their own ad-hoc extensions. * It's written in XML but there's no namespace, and implementations may or may not use namespaces for their extensions. Is an int64 represented as `i8` or `{http://ws.apache.org/xmlrpc/namespaces/extensions}i8 http://ws.apache.org/xmlrpc/namespaces/extensions}i8`? Depends on which library you're talking to! * There's a native "date/time" type, but the syntax is unspecified other than being ISO8601-ish. Don'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. * The XML-RPC spec claims that <string> elements can be used to transmit any character except '<' and '&', including binary data, including NUL. 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 big blob of fucking binary data in the middle of the document. Why was this allowed when the spec also defines a <base64> element?? The XML-RPC spec ought to come with a Surgeon General's warning that reading it might give you brain worms.
- masklinn 4y ago
  > I'm convinced the author was not aware of attributes, or for some reason held a grudge against them. That is completely unsurprising, attributes suck ass for data, what would XML-RPC even have used them for? Replacing <int> by <integer width=“32”>? Other serialisation formats make the same choice (e.g. plists) because it’s so much simpler. > There's only like five primitive types, so implementations that want to transmit wild and unusual values such as 64-bit integers need to define their own ad-hoc extensions. An issue which, which very much unfortunate, is not exactly shocking. Json would have the same if it had integers in the first place. > including binary data, including NUL Nul is a perfectly valid UTF8 character.
  - jmillikin 4y ago
peckrob 4y ago
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. 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. And regardless, it was far easier to implement than SOAP, which was just a mistake unless you are fully immersed in the Java ecosystem.
JodieBenitez 4y ago
Still using JSON-RPC 1.0 over HTTP here: - specs so simple it'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's just JSON - not too heavy compared to XML-RPC - as performant as your JSON serializer/deserializer - None of the ReSTish philosophical questionings - understood by developers of any generation: call methods with parameters
- to11mtm 4y ago
  also: > - None of the ReSTish philosophical questionings Adding to this, - If you ever -do- need to drop to something else (i.e. GRPC, websockets) you're not having to re-translate all of your restishness into commands.
- jiggawatts 4y ago
  Simple my arse: https://news.ycombinator.com/item?id=16897061 https://news.ycombinator.com/item?id=16897061 JSON, especially for multi-hop RPC, is a minefield of security and compatibility issues because the spec is too simple in a way, making it very complicated to handle safely and securely.
jeffrallen 4y ago
I used it just the other day to talk to a Flectra server.
moomin 4y ago
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.
kstrauser 4y ago
Just to repeat what everyone else is saying: it was awful, but a whole lot better than SOAP. 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. If JSON had widely existed at the time, and someone would have shown it to me, they would’ve been my friend for life.
- colonwqbang 4y ago
  Why did it take so long for people to come up with something like JSON? Why did we start out with such overly complicated formats?
  - icedchai 4y ago
    Tech is driven by fads and developers perpetually chasing the next shiny object. XML was the flavor of the day back in the late 90's.
incanus77 4y ago
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. 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. Yes, XML and related tech is fairly horrible, but context is everything. If you were running servers, there was enormous pressure to use Microsoft. 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. You would email code patches around. There was no GitHub, and SourceForge was only starting to gain traction. If were using open source version control in this era, you were likely on CVS, which was an "improvement" over RCS, but still nothing like the promised future tech of Subversion, which wasn'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). 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. Fairly-literal text was bloated, slow, and XML even more so, but it was all pretty cutting edge for the time. [1] https://www.xml.com/pub/au/11 https://www.xml.com/pub/au/11 [2] https://ubersmith.com https://ubersmith.com [3] https://git.drupalcode.org/project/drupal/-/blob/4.0.x/includes/xmlrpc.inc#L443 https://git.drupalcode.org/project/drupal/-/blob/4.0.x/inclu...
- nolok 4y ago
  Anyone who touched SOAP or CORBA for any amount of time larger than an hour have fond memories of XML RPC, despite all the flaws. I know I do.
  - icedchai 4y ago
    SOAP was also incredibly verbose, but being able to generate both client code and server stub code off of the spec (WSDL) was useful. There was no tedious hand coding of clients like you'd often see with REST.
davewiner 4y ago
I wrote a post about this thread. I am the author of the XML-RPC spec and co-designer of the format. http://scripting.com/2022/07/16.html#a172934 http://scripting.com/2022/07/16.html#a172934
soapdog 4y ago
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.
TFortunato 4y ago
"Fun" Fact: ROS (the "Robot operating system") has used XML-RPC under the hood for many years. While it'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. http://wiki.ros.org/ROS/Technical%20Overview http://wiki.ros.org/ROS/Technical%20Overview

retrocryptid 4y ago

It's important we publish things like this so the next generation will know what not to do.

gusfoo 4y ago

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

pjmlp 4y ago
Only when developers insist in using stuff like vi to write it by hand.
- jkmcf 4y ago
  I always expected the great boon of XML to be a proliferation of tools leveraging XSD to provide GUIs for managing the XML files. XML seemed like a great way to manage config files, but even auto-complete wasn't enough IMO. I'm thinking specifically about Apache Jakarta config files. Not sure if any ever existed. Of course, I'm unsure if XSDs were much used outside of big Java shops.
  - pjmlp 4y ago
    They did exist, on the domains where development tools actually get paid for.

tannhaeuser 4y ago

Aah xml-rpc; don't know why it is found interesting these days but still .., My thinking is: if you employ a relative high-ceremony meta-language such as XML as service payload format, then you'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't give you that and imposes param=values logic known from simple URL-encoded invocation forms instead, improving little over those. Then SOAP was introduced as the big unified payload serialization format covering document- and RPC-oriented uses. We all know just how it sucked. But then came the even worse end result/eternal September of "REST" APIs - a misuse of HTTP and blatant and painful misappropriation of Fielding's concepts, whose proponents used SOAP's flaws as an excuse for their anti-engineering practices.

outofmyshed 4y ago
If REST APIs are the worst, how does that account for their immense utility and popularity? I wrangled XML-RPC and SOAP back in the day. It was bad enough when you had exactly the same stacks talking to each other. When you had to interop between systems, ie .NET talking to Java, which was half the point of it all, it was a whole new circle of hell.
- akx 4y ago
  Trying to get Python SOAP stacks to talk to Java/.NET banking services was another thing too. I still get mild PTSD from thinking about XMLsec and XML c14n.
- Pamar 4y ago
  I have to disagree. I used XML-RPC exactly twice, but it proved to be a quick solution to nasty integration problems and we were very happy with it. Case #1 - we had to implement an interface to book flights on Amadeus (https://amadeus.com/en https://amadeus.com/en). In order to guarantee the caller identity they provided a C library (binaries that you had to link with your stuff) that would generate tokens that you would then add to your own calls to them to guarantee your identity. We were trying to use it from a Solaris machine, and the library would bomb at each call. But their Windows binary module worked fine, so we basically put up an XML-RPC connection between our Solaris hosted main app and a little Windows service which would simply provide the token for us to embed in the subsequent call. (This was the only way we could find to hit our release date in time, and it worked fine for 5 years serving hundred of thousands of calls every year). Case #2 - less "business critical", but still fine: I was on sick leave from the office recovering from minor trauma to my knee and here is what I suggested to a guy trying to use a PERL library as part of non-PERL stack: https://stackoverflow.com/a/2635719/54504 https://stackoverflow.com/a/2635719/54504 (it was part of his final exam for a degree in CS, I provided more assistance outside of StackOverflow and he was very happy with the results).
- tannhaeuser 4y ago
  Yes SOAP interoperability sucked, no arguing about that. The fact alone that you needed interoperability guidelines (WS-I) on top speaks volumes about W3C's derailed standardization effort - a similar problem is hunting today's OAuth standard btw. But just that SOAP sucks doesn't mean "REST" is ideal. Fallacy of the excluded middle and all.

jmillikin 4y ago

I've had the great misfortune to be writing code against an XML-RPC service recently. It's really a miserable design, even compared to contemporaries like Sun RPC. * Incredibly verbose. Even a trivial array value like [1, 2, 3] encodes to over a hundred bytes. I'm convinced the author was not aware of attributes, or for some reason held a grudge against them. * There's only like five primitive types, so implementations that want to transmit wild and unusual values such as 64-bit integers need to define their own ad-hoc extensions. * It's written in XML but there's no namespace, and implementations may or may not use namespaces for their extensions. Is an int64 represented as `i8` or `{http://ws.apache.org/xmlrpc/namespaces/extensions}i8 http://ws.apache.org/xmlrpc/namespaces/extensions}i8`? Depends on which library you're talking to! * There's a native "date/time" type, but the syntax is unspecified other than being ISO8601-ish. Don'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. * The XML-RPC spec claims that <string> elements can be used to transmit any character except '<' and '&', including binary data, including NUL. 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 big blob of fucking binary data in the middle of the document. Why was this allowed when the spec also defines a <base64> element?? The XML-RPC spec ought to come with a Surgeon General's warning that reading it might give you brain worms.

masklinn 4y ago
> I'm convinced the author was not aware of attributes, or for some reason held a grudge against them. That is completely unsurprising, attributes suck ass for data, what would XML-RPC even have used them for? Replacing <int> by <integer width=“32”>? Other serialisation formats make the same choice (e.g. plists) because it’s so much simpler. > There's only like five primitive types, so implementations that want to transmit wild and unusual values such as 64-bit integers need to define their own ad-hoc extensions. An issue which, which very much unfortunate, is not exactly shocking. Json would have the same if it had integers in the first place. > including binary data, including NUL Nul is a perfectly valid UTF8 character.
- jmillikin 4y ago

peckrob 4y ago

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. 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. And regardless, it was far easier to implement than SOAP, which was just a mistake unless you are fully immersed in the Java ecosystem.

JodieBenitez 4y ago

Still using JSON-RPC 1.0 over HTTP here: - specs so simple it'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's just JSON - not too heavy compared to XML-RPC - as performant as your JSON serializer/deserializer - None of the ReSTish philosophical questionings - understood by developers of any generation: call methods with parameters

to11mtm 4y ago
also: > - None of the ReSTish philosophical questionings Adding to this, - If you ever -do- need to drop to something else (i.e. GRPC, websockets) you're not having to re-translate all of your restishness into commands.
jiggawatts 4y ago
Simple my arse: https://news.ycombinator.com/item?id=16897061 https://news.ycombinator.com/item?id=16897061 JSON, especially for multi-hop RPC, is a minefield of security and compatibility issues because the spec is too simple in a way, making it very complicated to handle safely and securely.

jeffrallen 4y ago

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

moomin 4y ago

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.

kstrauser 4y ago

Just to repeat what everyone else is saying: it was awful, but a whole lot better than SOAP. 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. If JSON had widely existed at the time, and someone would have shown it to me, they would’ve been my friend for life.

colonwqbang 4y ago
Why did it take so long for people to come up with something like JSON? Why did we start out with such overly complicated formats?
- icedchai 4y ago
  Tech is driven by fads and developers perpetually chasing the next shiny object. XML was the flavor of the day back in the late 90's.

incanus77 4y ago

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. 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. Yes, XML and related tech is fairly horrible, but context is everything. If you were running servers, there was enormous pressure to use Microsoft. 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. You would email code patches around. There was no GitHub, and SourceForge was only starting to gain traction. If were using open source version control in this era, you were likely on CVS, which was an "improvement" over RCS, but still nothing like the promised future tech of Subversion, which wasn'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). 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. Fairly-literal text was bloated, slow, and XML even more so, but it was all pretty cutting edge for the time. [1] https://www.xml.com/pub/au/11 https://www.xml.com/pub/au/11 [2] https://ubersmith.com https://ubersmith.com [3] https://git.drupalcode.org/project/drupal/-/blob/4.0.x/includes/xmlrpc.inc#L443 https://git.drupalcode.org/project/drupal/-/blob/4.0.x/inclu...

nolok 4y ago
Anyone who touched SOAP or CORBA for any amount of time larger than an hour have fond memories of XML RPC, despite all the flaws. I know I do.
- icedchai 4y ago
  SOAP was also incredibly verbose, but being able to generate both client code and server stub code off of the spec (WSDL) was useful. There was no tedious hand coding of clients like you'd often see with REST.

davewiner 4y ago

I wrote a post about this thread. I am the author of the XML-RPC spec and co-designer of the format. http://scripting.com/2022/07/16.html#a172934 http://scripting.com/2022/07/16.html#a172934

soapdog 4y ago

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.

TFortunato 4y ago

"Fun" Fact: ROS (the "Robot operating system") has used XML-RPC under the hood for many years. While it'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. http://wiki.ros.org/ROS/Technical%20Overview http://wiki.ros.org/ROS/Technical%20Overview