"Stephen D. Williams" wrote:
> > RFC 2616, section 9.5 (POST), combined with some sort of purchase-order
> > schema.
>
> That simply amounts to 'I'll lob a blob of data over the wall'. Everyone who
> implements with this spec will do something very different unless you develop
> standardized semantics.
What matters is the interface; purchase order in, something out
(purchase receipt, confirmation, whatever). Specify that (the schemas),
and let the pizza places implement it according to their internal
business processes, behind the POST method.
I'll respond to the "lob" comment below.
> If you have specific problems with SOAP RPC rather than a particular XML
> Schema style, that would be a legitimate argument.
Unclear what you mean.
> > > What would I use with HTTP?
> >
> > The same, except you'd submit it with POST rather than with
> > nameYourOwnMethod.
>
> Ok, now you have really lost me. This is the example in the SOAP reference I
> have, given:
>
> From: http://static.userland.com/xmlRpcCom/soap/SOAPv11.htm
>
> Example 5 Similar to Example 1 but with a Mandatory Header
>
> POST /StockQuote HTTP/1.1
> Host: www.stockquoteserver.com
> Content-Type: text/xml; charset="utf-8"
> Content-Length: nnnn
> SOAPAction: "Some-URI"
>
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>
> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
> <SOAP-ENV:Header>
> <t:Transaction
> xmlns:t="some-URI"
> SOAP-ENV:mustUnderstand="1">
> 5
> </t:Transaction>
> </SOAP-ENV:Header>
> <SOAP-ENV:Body>
> <m:GetLastTradePrice xmlns:m="Some-URI">
> <symbol>DEF</symbol>
> </m:GetLastTradePrice>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
>
> We could argue about the SOAPAction:, but it certainly looks like it's using
> POST to me.
It's using POST, but is not posting a "business document".
>From RFC 2616,
"The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line."
In other words, there's meant to be an implicit structural relationship
between the URL and the entity POSTed to it. The relationship is one of
containment, where the entity is to be considered a child of the
resource represented by the URL. Or in other words, the implementation
managing that URL provides the context for the interpretation and
maintenance of the entities POSTed to it. This is a far cry from "lob a
blob of data over the wall".
Why go to the bother of hiding GetLastTradePrice inside a POST body when
it's clear that the semantic that is trying to be achieved here is
something approaching GET? Why not define a URL,
http://foo.org/LastTradePrice?stock=DEF ? Then you could just GET that,
even from a browser. If you just want the price, don't set your Accept
header to text/html, but use "application/x-stock-price+xml" (if you
wanted to use XML, and perhaps a XML Schema datatype) or "text/plain"
and set up your app to handle it.
> Except for available duplex and streaming mode differences, message based
> API's are the same as and RPC. Whether you have (messagetype=order, item=bla,
> ...) or order(item=bla, ...) makes no difference, just syntatic/semantic
> sugar.
No, it's not sugar at all. There's an implicit semantic in your first
case,
namely one of "accept", i.e. accept(messagetype=order,item-bla). At
that
level, much useful work can be done. For instance, the receiver end can
say "sorry, I don't know about "order"", or it can say "ok, thanks, I'll
get to this later", or "I know what an order is, but a header includes
some
metadata marked mustUnderstand="1" that I don't understand", or ideally,
"thanks, done" (or "thanks, done, here's a confirmation report").
Now think of POST as "accept".
> > > The SOAP level of detail is needed on top of your examples above. While some
> > > kind of middleware could be blissfully unaware of the details, actually
> > > programs need to know that in 'Headers h' is "first=Mark&Last=Baker", etc.
> >
> > Yes they do. But this doesn't have to be part of the interface.
> > Requiring it to be sacrifices genericity.
>
> I am totally a meta-data/data driven/small languages nut. I always like to
> build tools and infrastructure and as little application-specific code as
> possible. Always solve the meta-problem. Still, at some point, application
> code has to deal with specific variables, operations, algorithms, etc. You
> can't be generic all the way down.
Right, but you can maintain genericity of the interface in most cases.
That's all I'm talking about, the interface. Go wild on the
implementation
as you must, just please try to expose it through the interface defined
by HTTP. You can expose it other ways if you have to, but having an
HTTP interface to it is pretty cool. At the very least, just make it
GET accessible, so that people can link to your service. Having an URL
that can't respond to a GET just ain't right.
> > Yes, I know some people want to go further. I personally don't think
> > it's necessary, but it's a small enough thing that I can deal with it.
> > Certainly with the envelope structure SOAP requires in order to realize
> > its raison d'etre (namely, actor and mustUnderstand), an encoding is
> > required.
>
> If there is an argument with the semantics that SOAP expects not always being
> appropriate, that could be an interesting argument. I don't like
> COM/DCOM/COM+ that much.
Excluding RPC (and one other thing that I prefer not to go into for fear
of opening up a can of worms), I don't have much of a beef with SOAP.
It addresses a couple of shortcomings with HTTP that is very useful in a
personal project I'm working on, so it's ok.
I'm not sure what you mean about the "semantics that SOAP expects".
SOAP defines no application semantics of its own (a good thing), making
it usable over multiple application protocols. It therefore doesn't
expect any application semantics.
> > This isn't the first time I've heard this statement. HTTP can handle
> > XML just fine, thank you very much. I agree that we should look for
> > ways to better integrate the larger XML picture with HTTP, such as the
> > work done on draft-murata-xml, but XML-as-HTTP-payload is pretty darned
> > powerful as-is without any further agreement required.
>
> Defining the XML payload is still a big job right now when it's wide open.
But that's what all the industry specific schemas are for! That's what
gets carried directly on HTTP POST, or in the SOAP body.
If you mean the encoding, then ok, but it's not essential to standardize
IMHO.
> > > Detailed expositions of your view would be helpful. All uses of EDI, remote
> > > messaging, remote database, etc.
> >
> > The best I can do in a pinch is Roy's paper;
> >
> > http://www.ics.uci.edu/~cblake/Hyperware/Fielding1.pdf
>
> A good requirements starting point. Some good ideas, several bad ones.
Such as?
> If you are proposing an alternative to SOAP using existing technology, it
> should be simple to illustrate a strawman example we can beat on.
Nope, no alternative to SOAP, just an alternative (in most cases) to the
RPC use of SOAP; HTTP.
> I certainly question some parts of SOAP, but the general direction looks
> reasonable at this point. The idea of standard schemas WITH standard
> encodings makes sense and SOAP seems to add to this.
I agree. Both those things are independant of any RPC use of SOAP.
MB
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:17:50 PDT