Think the problem isn't so much SOAP::Lite but rather that SOAP itself is a joke - way too complex - designed by committee, supporting use cases that will only ever exist for 0.0001% of it's users.

And it's a protocol on top of a protocol (HTTP normally) - that already makes for a debugging / testing disaster.

Anyway, architects do like it in respect to working over long relationship distances: between departments that do not work closely or between companies. In the end, it is nice because it is a common protocol with tools written around it that save a lot of time. I don't have to worry about the underlying protocol, so long as my language can handle it. HTTP is the default since it's by far the simplest for synchronous message passing. It can be communicated by SMTP, FTP and SCP asynchonously.

Look at it like this. REST is simple. You need to usually develop your own library to access a REST service, but the REST service is fairly well documented if it is in any way popular. I'd argue PM's XML format to be like that, once you find the docs. :) Anyway, you have to relearn how someone implements rest. Speaking of which, you argue that SOAP is done over HTTP by default. What do you think REST services tend to be written over? :)

SOAP is simple for those who know SOAP. People who know SOAP know what NOT to do, and what TO do to make working easy. People, including myself, have the tools to takea WSDL (Soap descriptor) file and turn it into a stub in minutes, w/ far less reading to do and less code to write. It's the ability for a person to go from one SOAP shoppe to another, or for one SOAP user to use many shoppes at once, w/o relearning SOAP, is its power.

Look at it like this. REST is simple. You need to usually develop your own library to access a REST service, but the REST service is fairly well documented if it is in any way popular. I'd argue PM's XML format to be like that, once you find the docs. :) Anyway, you have to relearn how someone implements rest. Speaking of which, you argue that SOAP is done over HTTP by default. What do you think REST services tend to be written over? :)

I don't view REST as being written "over" anything; rather, it's using HTTP to a fuller extent. For instance, a web service may require user/pass authentication. Many of them do it something like this:

GET /path/to/service?user=foo&pass=bar HTTP/1.1
Host: foobar.com

HTTP/1.1 200 OK
[other headers]
Content-Type: text/plain

Error: Username/password invalid
[download]

This was acceptable practice back when CGIs were the standard. These days, mod_perl (and equivilents for other languages and servers) let us hook into the server more deeply, including taking over the authentication layer, so we can handle authentication using the headers HTTP already has:

GET /path/to/api?name1=value1&name2=value2 HTTP/1.1
Host: foobar.com
Authorization: Basic Zm9v0mJhcg==

HTTP 401 Unauthorized
[Other headers]

[Optional return data]
[download]

The advantage here is that you often don't have to write a new library, at least for these common things. LWP::UserAgent (and other WWW libaries) already knows how to do HTTP basic and digest authentication, and its is_success() method should return false for a 401 HTTP response.

The more complex parts of your application will always require code, of course, but letting HTTP handle the things HTTP knows how to handle means that you can focus on the harder bits.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

You have to write a library to parse the response and generate the correct request, not for the underlying HTTP(S) protocol.

For your example, I have to parse "Error: Username/password invalid" into something, anything. The simplest way to handle this in soap is to throw a fault and do something like $response->get_fault->get_error_message.

Have to dispute some things...

SOAP is an RPC-esq way of doing message passing in a language agnostic way.

...except when it isn't, such as when document/literal encoded - reasonable description here.

The intention, I believe, is to cover all bases.

There in lies the whole problem - design by committee. Many of the use cases were fantasy - something vendors where / are hoping to sell in the SOA orgy. That's compared to REST, which was an abstraction principles and experiences gained with HTTP and what went before it - specifically REST isn't trying to be a one size fits all - Roy Fielding explicitly describes the things it's bad at.

Wrong. It's a format protcol, so to speak. It's a method of formatting a messgae call, or a function call which is a fancier message call.

So what's the addressing scheme for? And how did we get to HTTP over SOAP?. Also document / literal style services aren't about calling remote APIs - what you describe is only a subset of SOAP - Encoded / RPC over HTTP.

SOAP is simple for those who know SOAP. People who know SOAP know what NOT to do, and what TO do to make working easy. People, including myself, have the tools to takea WSDL (Soap descriptor) file and turn it into a stub in minutes, w/ far less reading to do and less code to write. It's the ability for a person to go from one SOAP shoppe to another, or for one SOAP user to use many shoppes at once, w/o relearning SOAP, is its power.

I know where you're coming from but in the end that's the illusion of SOAP - it feels good when everything "just works" like this. But the moment it doesn't, you got a huge stack of code to debug + verbose wire formats (can you do XSD by hand?). And with networks involved, there are a lot of things that can go wrong. And have mercy the moment you need to scale to anything but low volume Intranet / Extranet interfaces...

All I can do is express the opposite point of view with the following code;

#!/usr/bin/perl -w
use strict;

use Carp;
use LWP::Debug qw(+ -conns);
use LWP::UserAgent;
use XML::Simple;
use Data::Dumper;

my $ua = LWP::UserAgent->new;

my $res = $ua->get('http://perlmonks.org/?displaytype=xml;node_id=3333
+');

if (!$res->is_success) {
    croak("Failed!\n".$res->as_string);
}

print Dumper XMLin($res->content);
[download]

It's got error handling, a trace of the "raw" HTTP conversation and it gives you an instant data structure to examine. It's relatively easy to extend this to support conditional GETs and you're already on your way to preserving bandwidth / scaling.

We can argue the ins and outs of this ad infinitum but from my perspective, simple always wins.

...except when it isn't, such as when document/literal encoded - reasonable description here.

You're splitting hairs. :) A function call is simply something to the effect of a receiver getting some information and responding to it. A document/literal encoded message in SOAP is a receiver getting some information, processing it as it sees fit, and responding to it. The differences are semantics. They act the exact same in the general scheme of life, love, and the persuit of beer.

Many of the use cases were fantasy - something vendors where / are hoping to sell in the SOA orgy.

examples? Im curious.

So what's the addressing scheme for? And how did we get to HTTP over SOAP?. Also document / literal style services aren't about calling remote APIs - what you describe is only a subset of SOAP - Encoded / RPC over HTTP.

The endpoint url? It's not required. An engine will ask you for an endpoint, some place to deliver a message. I can route soap over smtp/e-mail and process it as an asynchronous queue. Document passing IS a form of rpc in that the receiving side looks at the message and decides what to do w/ it. the only difference between formal rpc and document passing, is in the nomenclature. In the end, you are sending a message, a message as a document or a message in a more common "function call like document" that warrants a response.

So why HTTP? Why not? Most people were doing RPC (REST and so forth) over various protocols. HTTP is most popular. Again, SOAP is a format protocol for messages, documents and what not. It's not reliant on networking or anything of that nature.

I know where you're coming from but in the end that's the illusion of SOAP - it feels good when everything "just works" like this. But the moment it doesn't, you got a huge stack of code to debug + verbose wire formats (can you do XSD by hand?). And with networks involved, there are a lot of things that can go wrong. And have mercy the moment you need to scale to anything but low volume Intranet / Extranet interfaces...

All generalizations are wrong. Sadly, I've done debugging on soap interfaces when something has gone wrong, either a bug in a toolkit, or something jsut didn't feel right. Once you know how, it's easy. Learn soap, learn soap toolkits, and basic soap debugging, and it becomes portable. Sorry, this "illusion" and "bullshit" (from earlier) is subjective.

It's got error handling, a trace of the "raw" HTTP conversation and it gives you an instant data structure to examine. It's relatively easy to extend this to support conditional GETs and you're already on your way to preserving bandwidth / scaling.

That's nice you can dump the content of an XML feed, but now you need to execute an XML parser over it and examine the XML content. Also, you have to format the url. In a soap-esq ay, I would do something like

$pm->set_target("http://perlmonks.org")
$pm->get_node(333)
$pm->get_node(334)
$pm->get_node(335)
[download]

We can argue the ins and outs of this ad infinitum but from my perspective, simple always wins.

Not arguing who's right, who loses and all that BS. This is computer engineering and software design. Only thing that wins in the end is what works. If you can use REST, great. Awesome. I know many people who use it successfully. I personally prefer SOAP simply because I don't have to worry about XML parsing, recreating an object model and the likes.

An annecdotal example: I had to work with salesforce.com, a CRM system once. I needed to pull a user's information, and sync it to a local user's records depending on the situation. I got their quickstart document, explaining the calls and the wsdl. Took the WSDL, generated the code and was up to the debugging point within minutes. The debugging points were things like calling their APIs in a certain order, which ones I should use for efficiency, and various other things like trying to divide by zero due to my own stupidity.

Another annecodal example: verisign uses rest. I grabbed their document and started writing code agaist their target url. I reconstructed an object model, by hand, that worked around the data being sent and retrieved. I implemented the communications by hand, parsed the responses by hand and sent out the request, by hand. I was up rather quickly after debugging all the code I wrote.

In the end, I ran into little troubles with either. w/ the SOAP implementatoin, I had LESS code to write and was faster to get working because of the standard. Now, I'm not trying to convince you to use SOAP over REST. Use whatever you wish, it's ok. But please, don't spread misinformation if it can be helped :)

p.s. we got to http and soap because you mentioned it in your primary node on the subject. mind you, those http:// things in the document are not only URLs, but URIs.

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383532

And yes, you can put headers in a soap message. Same as you can put headers in an email. That IS how email works, you have the SMTP envelope, and then the headers, which normally agree, unless yer a spammer. Anyway, headers are meta-data in soap. You can put constructive, request level data, in there, such as serial number, security info, a token of some sorts, etc etc..

But what really motivated my post is that my company has several large customers who use Perl SOAP clients to access our API. We are improving that API quickly, and we are trying to avoid recommending to our customers that they port their Perl SOAP client code to Java or Ruby.

Why not implement example Perl clients to show them how to do it?