Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
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.