XML-RPC versus HTML Form

Question

Can anyone explain to me the benefits of using XML-RPC over a straight HTML Form ? On first glance, they seem to accomplish the same thing. The XML-RPC is "formatted" using XML, but you can do the same in a form (think textbox).

I have an app that takes data from a script that runs on the client PC. The output from the script is XML. Currently it is submitted to the app (PHP using CodeIgniter) via a form POST. I have been told to look at using XML-RPC, but I am trying to understand "why"...

Answer 1

I primary benefit of XML-RPC is that you don't have to write any (or nearly any) glue code to get remote processes to communicate. There are a wide variety of XML-RPC client libraries available for many languages. In the case that you have a rich API of functions, XML-RPC can be a very easy way connect remote processes to that API. Performing the same task with a plain www-form-encoded POST will require you to convert an API to a form and dispatch requests into api calls. There are a few systems that can help with that, but it is certain to be more difficult than just exposing the API through XML-RPC.

On the other hand, if (as it sounds) you already have a rich API exposed through plain form encoded requests, It's hard to justify the work of porting both client and server to another interface.

Answer 2

If you mean encoding data in the www-form-encoded (or "query string style") format vs POSTing XML-RPC, it's really a matter of taste. Some people prefer to use XML for everything.

Answer 3

XML-RPC is a bit dated, in my opinion. Unless you're talking about a different protocol, this is the one that preceeded SOAP. I wouldn't use it at all. Instead, I'd either use a SOAP-based service, or a REST-based one.

Answer 4

HTML forms are not comparable to XML-RPCs.

You use HTML forms to get some input data through a WebPage, while you use XML-RPC to execute remote procedures using XML.

Usually you will use XML-RPC for a process without a UI trying to execute some procedure remotely.