[
Lists Home |
Date Index |
Thread Index
]
> From: Mike Champion [mailto:mc@xegesis.org]
<snip/>
> So, we apparently agree that REST raises issues that Web
> Services need to
> address. So how do people think the issues will be resolved?
Well, for one thing, I think there is an awful lot of dogma and religion
around REST. There are certainly sound principles in REST. But there are
also very real business problems that people are going to solve with web
services. If REST cannot support these, then the REST folks will lose
regardless of what theoreticians and spec committees have to say.
With that said, certainly web services should be sensitive to issues related
to web architecture. But when I hear a suggestion that every XML format that
will ever be submitted through an HTTP server needs to have a unique media
type assigned, I don't think that is an area where the web services folks
need to bend to REST. This is an area where REST needs to evolve. REST was
designed as an architecture for hypermedia systems. It has not proven itself
in the world of complex business process workflows, which is a key part of
what web services address. So treating it all as unquestionable truth is a
mistake. We are entering a new domain, and REST has to prove it is up to the
task.
When I read REST papers, many of the principles sound quite familiar to me.
They are things I was doing in distributed OO systems long before anyone had
written about REST (or at least long before any of the REST papers I've seen
publicly cited). Things like not maintaining session-state between client
and server, adhering to meaningful identifiers for objects (or "resources"
in the REST view) that can be leveraged by caching mechanisms, using generic
interfaces and limited sets of verbs. I've heard too many REST folks claim
they have insights that the OO folks don't understand. I haven't heard them,
yet. Of course, when I wrote those distributed OO systems, we also used
design patterns like Command[1], Composite[2], and Chain of
Responsibility[3] -- things that some REST folks insist are wrong. We used
them because they were useful and needed. I think web services have more to
learn from proven OO patterns than from REST, here.
Indeed, many REST folks seem fond of mischaracterizing OO. As one minor
example, I'm looking right now at the paper by Roy T. Fielding and Richard
N. Taylor [4] and find this quote:
Unlike the distributed object style..., where all data is
encapsulated within and hidden by the processing
components, the nature and state of an architecture's data
elements is a key aspect of REST.
Sun's J2EE blueprints[5] espouses a pattern they call "value objects" --
lightweight objects representing externalized state that can be exchanged
among components in the system. This is not a new pattern. I was using it in
distributed OO systems long before there was a J2EE or papers on REST.
Indeed, at the time I was using Forte 4GL, and Forte had a technote for
developers that explicitly advocated this pattern -- and for the same
reasons REST does. This is not new, and it is not counter to OO.
I would like anyone advocating REST to tell me the correct way to handle the
very simple case I have already cited [6]. If there is a better way to do
this, I'm happy to learn. But the only thing I've heard suggested so far is
to break this hierarchical composite into a bunch of smaller messages that
must be sent independently. If that's what REST says, then REST is wrong and
the web service community must recognize that the REST folks don't have all
of the answers we need. To break this composite into smaller messages would
be to expose dependencies (such as dependencies upon order of execution) to
the client that should not be exposed. I get challenged to prove that REST
cannot address all conceivable business functionality, yet this example is a
rather trivial one that no one has responded to, yet. If I cannot do even
something as simple as this with REST, how am I supposed to build enterprise
systems with REST?
I think it's for the REST folks to prove REST is up to the task, not for
others to prove REST can't do it. Apart from that, I'd be happy to see BEEP
or another more fitting protocol gain prominence enough for it to be a
viable option for me. I'm not wedded to HTTP. But I need real solutions, not
religion. I'm not hearing real solutions.
[1]
http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/command/int
ent.htm (not a helful link, but all I can find)
[2]
http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/compos/inte
nt.htm
[3]
http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/chain/inten
t.htm
[4] http://www.cs.virginia.edu/~cs650/assignments/papers/p407-fielding.pdf
[5] http://java.sun.com/blueprints/enterprise/index.html
[6] http://lists.xml.org/archives/xml-dev/200202/msg00376.html
|
