Well the bandwagon has finally reached us and we're implementing web services so the pretty desktop applications our C# developers write can have something to talk to.
I've been playing with SOAP::Lite and have a few questions:
Anyway it's all rather exciting, though I did web services back in 1999 with CSV over HTTP before it was cool.
Either way... (Score:3, Informative)
So, I think it depends on what you need. If you need things that SOAP has, use it. If you want something pretty damn simple, and easy to work with.. use XML-RPC. We had Wintendo guys interfacing with the services I created, co-workers understood the XML-RPC payload quickly, and had a decent grasp of the modules. So, I guess it also depends on your timeline and group-size.
In my case, I was using XML-RPC but had the option to plug-in SOAP if needed. All API modules were non-transport specific so all I had to do was open a new port. I wrote a custom application server to do it, then finally convinced people we should use Apache/mod_perl... since I was reinventing Apache with mod_perl
I got into many religious discussions between the two... but XML-RPC won out for what we initially needed. I also did many benchmarks (doing tasks we needed to get done) between XML-RPC and SOAP implementaions... XML-RPC won out every time.
Reply to This
XML-RPC v. SOAP: let's get ready to rumble (Score:2, Interesting)
I like both, although I gravitate toward XML-RPC both because I know it well and SOAP doesn't offer me additional power (strangely, this is precisely why I don't program in python much).
Both message procotols do Remote Procedure Calls. Method calls and parameters are serialized into XML and sent over HTTP. XML-RPC is simple and procedural. I have used it a lot and am actively developing a few applications that depend on this protocol. It's simple and and smaller than SOAP and does 99% of what I need. H
Re:XML-RPC v. SOAP: let's get ready to rumble (Score:2, Insightful)