Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Either way... (Score:3, Informative)

    by KM (4) on 2003.09.11 17:12 (#24132) Journal
    When I had to choose between SOAP and XML-RPC, I chose XML-RPC for what we needed. SOAP has more overhead, and we didn't really need to pass objects back, and if I had to teach people about namespaces in XML so they could understand how things worked, it would have never gotten off the ground. Last I heard, the SOAP spec may change, or was changing, or may not be backwards compatable. Someone else may know, it has been over a year since I was comparing the two in-depth.

    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.
  • 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

    • I don't think you could call SOAP "object-oriented" in any meaningful way. It has no concept of state management, so you can't instantiate an object and then call methods on it across the wire. It's just RPC with the ability to serialize complex data types.