[
Lists Home |
Date Index |
Thread Index
]
This is a somewhat long and rambling post. Sorry about this, but I've
thinking about this a fair bit (while still trying to absorb REST).
> From: Sean McGrath [mailto:sean.mcgrath@propylon.com]
<snip/>
> 2) SOAP will be transport independent. Doesn't that sound
> really appealing?
> This mantra is already gathering pace. The fact that most
> developers trust deep
> magic to make RPC work over both HTTP and SMTP without
> thinking about the fundamentally different transport model of
> each is testimony
> to how powerful that mantra is.
Although I am essentially won over to the REST perspective, now, I still
think most of the REST advocates who keep arguing against SOAP still largely
miss the appeal that SOAP offers to the average developer. I'm not
disagreeing with your points. But I'd like to add another perspective for
those who really want to win mindshare for REST among those attracted to
SOAP.
First, in terms of protocol independence, there is some appeal to being able
to accept a message via HTTP, queue it somewhere else (including simply in
the file system), and process it later without any loss of fidelity of the
information it contained -- and without having to transform all of the
pertinent information into a different format to accomplish this. That's
part of the appeal of being agnostic with protocol.
I'm not saying this is the right way of doing things. I'm saying that SOAP
developers care about the *information* -- not the document format or the
protocol -- and they want to be able to *easily* move that information
around without loss of fidelity. Fixating on proper use of HTTP doesn't seem
likely to offer a counter-solution. Defining a framework for smarter
protocol bindings that can support that ease of moving information around
while respecting protocols that get leveraged would seem like the right
avenue to explore. HTTP is not the center of the universe to the SOAP
developer.
Second, I honestly don't buy the notion that the average SOAP developer
really cares about RPC. I think the average developer cares more about the
APIs than the protocol. They want to work at a higher level with data
structures and APIs that are a *natural fit* for their programming language
of choice. I have yet to meet a business developer who likes working with
the DOM (or any equivalent model). This is the real appeal of SOAP RPC. I
see no reason why there could not be frameworks offering data-binding and
modelling resources as first-class objects with stongly typed methods for
doing things that abides by REST under the covers while providing the same
sort of ease-of-use that SOAP toolkits offer. Indeed, elevating the
addressable resources to first class objects in the model seems to offer a
richer model with which to solve problems. This seems like it is an
opportunity to win over SOAP developers. You'll have to wean them from
generating the XML formats from APIs, but I don't think this is a big leap.
I've seen tools marketed that let you generate an ER model from APIs, but I
have yet to see a real world project that uses them. Every project for a
database application in which I've been involved always made the data model
central, and designed the APIs out from that. It shouldn't be a big leap to
convince web services developers to do the same.
> 3) Developers will be urged to write to the SOAP "API"s
> exclusively in order
> to insulate their systems from transport dependencies. This will be
> marketed as something all conscientious developers should do.
It's what most developers *want* to do. They want easy to use APIs that are
more aligned with the business problem they are trying to solve than
protocol details. They don't want to have to muck with low-level protocol
details every time they need to solve a business problem. This is the EJB
model. How many EJB developers are there today, compared to those who deal
directly with CORBA or RMI? Is the success of EJBs just because of app
server vendors pushing it, or is there genuine appeal to the API-centric
approach? I think the latter is very much the case. The EJB model avoids
vendor lockin by standardizing the APIs rather than the protocol (except for
the fact that you are locked in to Java).
Obviously, web services standards need to focus on the protocol. I'm not
arguing otherwise. But we should lose sight of the appeal to developers. To
most developers, it the APIs that abstract away the details of XML formats
and networking protocols that are attractive.
<snip/>
> By the time they are doing that, I fear the world will have
> forgotten that REST
> presented an alternative, and I would argue significantly
> more powerful,
> data-flow based approach to building systems.
Unless some folks get out in front of this and offer toolkits for developers
that let them work with APIs and data structures that are a natural fit for
the programming language of their choice, but which also promote REST
principles. If the tool makes it relatively easy to take any first-class
object in the business model, and model it as a URI-addressable resource --
rather than making those objects opaque to the protocol -- there's a shot at
winning some mindshare.
Maybe I can steer my little side project [1] in that direction at some
point. But I have my hands full with some other goals for that, right now
(as well as my day job). I have been doing some thinking about this, though,
so I'll offer some of my current thoughts and see what people think.
REST advocates seem to look at things in a rather document-centric fashion.
There's nothing wrong with this model. But then, there is nothing wrong with
the model of those who want to view a document as just a bag of elements for
which the notion of any top-level document type -- or media type -- is not
particularly meaningful. If REST advocates want to win over the web services
community, they need to find the way to accomodate this model in REST rather
than insisting this model is wrong.
I think if REST is to appeal to the SOAP-RPC community, it needs to
accomodate a more granular and component-oriented notion of resources. For
instance, SOAP has the notion of pass-by-value or pass-by-reference. This is
a common notion in the programming world. One of the strengths of the SOAP
envelope is a reserved place for elements that describe shared context (e.g.
authentication info). Paul Prescod wrote in one of his articles (I forget
which one) that shared context should be modelled as resources. I like that
idea. But I still think we need a notion of pass-by-value. If one little
message requires the endpoint to start doing a bunch of 'GETs' across the
internet for all shared context, things quickly get out of hand. The OO
world is quite used to the notion of an object being an aggregate of other
objects. Subordinate objects may or may not be independently addressable. We
need a framework for modelling such notions in a REST-ful way.
There must be support for resources that are aggregates and that offer
representations for which the notion of a top-level type (other than XML
with namespaces) is not meaningful. The very fact that an RFC had to be
issued to try to let media types make peace with the XML world with an
"+xml" suffix (and the debate that swirled around that RFC) is clear
testament to the fact that there are broadly employed uses and processing
models for XML for which the notion of media type is useless (other than to
know it is XML). Any notion of web services that tries to shut down those
uses and processing models is doomed to fail.
There must be a way of conveying aggregated representations of resource
states. The latter could be made more REST-ful with hyperlinking. Any
business application relies upon some mechanisms for making objects
addressable. These could all typically be mapped to and from URIs. So maybe
we just need a modular convention for XML message formats that let you embed
some inline element annotated with an href (perhaps making the element an
Xlink simple link) that specifies the "home" URI for the resource
represented by that element. It's kind of a way of saying "here's the URI
for some shared context, but I've saved you the trouble of getting it by
including an inline state representation". If I have to tell a client to do
10 separate GETs to do something that can be done with one method call in a
typical non-REST-ful distributed app, there's a problem. I don't know that
this is anti-REST (that's not clear to me). I go back to an exchange that
Paul Prescod and I had awhile ago [2]. Paul's solution is an interesting
one, but I have a problem with the notion that I can't do this with a single
XML document. It seems like this could be made to work with REST if the
resource representations are not opaque. If we can recognize links in them
(e.g. via XLink), then we should be able to define conventions by which we
can also recognize inline state representations of other resources, and that
could afford some richer processing models. Does this make sense? The
recipient of such a message could recognize the inline state representations
for what they are, and know what resources they represent and be able to
address them independently since it also has their URIs.
A further convention for distinguishing between those that represent shared
context, and those that are directly pertinent to the resource being
addressed, also seems useful. The SOAP envelope and conventions partially
address this (with its notion of Header vs. Body). It falls short in failing
to model these inline objects as addressable resources in their own right.
What's a better way of doing this?
Well, that's some of my thinking this week on this stuff. Any merit to this?
[1] http://swan.sourceforge.net/
[2] http://lists.xml.org/archives/xml-dev/200202/msg00444.html
|
