[
Lists Home |
Date Index |
Thread Index
]
Michael Brennan wrote:
>
>...
>
>
> 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 agree 100%. But isn't that what XML buys you? "Regular" protocols
actually move the data around. XML describes the data. You talk about
not loosing any fidelity. I feel a lot more confident about transporting
my XML around in a data format that neither knows nor cares thta it is
XML (like HTTP or SMTP) than with SOAP.
If you can tell me what you're getting from SOAP then I can have a
better idea of whether there is something missing from the historical
protocols.
> 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.
Yes, data binding is important for ease of use. If you look at the
prototype WRDL API you'll see there is no DOM stuff involved.
res = r.GET_meerkat_xml_flavour( channel=555,
timePeriod="7DAY", search="Prescod")
text = res.body() # get resource body
assert text.find("Prescod")>0 # vanity assertion
# get a list of references (XML or HTML hyperlinks)
links = res.references("link")
assert len(links)>1 # sanity check
# download representation of first link
newres = links[0].GET()
>...
> 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.
I would disagree with this point. You can't get interoperability until
you standardize the structure of the "bag of elements" and that requires
thinking in terms of documents. Maybe the business application developer
doesn't need to, if they just choose a vocabulary, but somebody had to
design the vocabulary so somebody has to be thinking in terms of
document ypes.
I'll need to think about your other ideas another day when I have more
time...
Paul Prescod
|
