[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
> When you say it looked alot like SOAP do you mean to say that
> it did XML
> over HTTP or do you really mean that it was structured in some
> substantial way like this:
>
> * http://www.w3.org/TR/soap12-part1/
> http://www.w3.org/TR/soap12-part2/
Whoa! SOAP sure has gotten more complex since the last time I looked at the
specs! I'll have to confess I haven't been following the progress of the web
services activity for awhile.
The approaches I've seen have some similarities to that in the "part1" spec,
though typically simpler (and none of the sort of RPC-specific stuff in
"part2").
The model I've seen developers gravitate toward is using a simple
request/response model where everything is POST-ed through coarse-grained
entry point URLs. HTTP was just used for convenience; we tunneled through
it. HTTP semantics were not leveraged other than to get the XML from one
point to another.
We tended to define generic "Request", "Response", and typically also
"Error" XML envelopes that were used to wrap specific XML commands. So we
had a request/response model where everthing of interest is in the XML
message.
I've never used a real RPC model. We always started by modeling the message
structures, then building the implementation out from there. But the XML
messages had tags that were interpreted as fine-grained commands (though
syntax was always abstracted from implementation).
That's what I meant by "SOAP-like". I was speaking in terms of some
high-level patterns. I see some common characteristics between the
approaches I've seen adopted and SOAP, and they all seem to share most of
the same issues in terms of conflict with REST.
|
