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.
Turning to specifics, though:
- What security do you mean other than HTTPS? Roles and stuff?
The usual: encryption and signing.
HTTPS is not truly end to end.
- 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.
That is two.
- Standard error handling sounds interesting; it's true that HTTP error
codes aren't exactly a rich vocabulary. What does SOAP have?
Exceptions/SOAP fault.
- 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.
Since when has it been an advantage that semantics are not
well defined?
XML and a schema is absolutely necessary if it has to be structured.
- 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.
Again there is a difference between what is sufficient to be REST and
what is necessary to work well.
A structure for URL is necessary if it has to be structured.
In practice that means hierarchical.
Which can be considered a virtual file system.
Arne