Re: how does one talk to a web service? What makes something a web service?
Tom Anderson wrote:
On Sun, 28 Jun 2009, Mike Schilling wrote:
Tom Anderson wrote:
There isn't the level of tool support around REST that there is
around the SOAP stack. But then it's not clear it's needed,
because
REST is so simple - you form a URL, download it, stick the XML in
a
parser, and you're away.
Of course, one the REST folks decide they need security, or
transports other than HTTP, or standard error handling, or to
interpret their XML representations as objects, or to model things
that don't map neatly to virtual file systems, it'll be fun to see
REST get more and more complex until the next "But this is so much
simpler" approach emerges.
There's some truth in that. But they'd have to really, really cock
it
up before it was overcomplicated as the SOAP stack.
What's so complicated about SOAP?
Turning to specifics, though:
- What security do you mean other than HTTPS? Roles and stuff?
There's lots of reasons to do application-level security instead of
transport level. Roles is one. Another is to maintain a security
context across routers. A third is to map users across security
realms.
- What transports other than HTTP? If they're so important, why
isn't
anyone using SOAP over them? There are a vanishingly small number of
uses of SOAP over email, and some SOAP over JMS, but nothing else in
any serious way.
SOAP over JMS is used on a significant number of intranets.
Transactions that don't fail because one node is down can be crucial.
- Standard error handling sounds interesting; it's true that HTTP
error codes aren't exactly a rich vocabulary. What does SOAP have?
Faults, which contian arbitrary amounts of user-defied conent and map
naturally to exceptions.
- The question of representing XML as objects is a red herring. REST
moves XML (or JSON or whatever). What you do with that XML is up to
you, and although it does need to be dealt with, the way that's done
doesn't need to be uniform across clients, because the interface
itself is defined in terms of the XML.
Which makes it difficult to map the XML to programming language
constucts, or to generate or verify programmatically.
- REST has nothing to do with virtual file systems. You're confusing
meaningful URLs with REST - they're actually *completely* unrelated.
A lot of people thing REST means urls.th.at/look/like/this, but
that's mistaken. In REST as defined in Fielding's work, URLs are
opaque - you could write a REST API in which all the URLs looked
like
/api/d056889d45 and it would still be REST. In Fielding-approved
REST, you never construct URLs, you always obtain them from some
resource you've been served (i think the idea is called
'hyperlinks',
you may have heard of it), so their structure is never relevant.
Sure, but the notion that all you'd ever want to do with them is look
them up, GET them and PUT them amounts to it being a hyperlinked file
system. Many applications are more interesting than that.