Re: another approach to status codes, etc. in HTTP binding

 Mark,
 I do agree that PUT and POST, for example, are very different in
their semantics and very usable in some situations. What I wanted
to show was that, for example, you wouldn't use the HTTP PUT
method for SOAP communication. You could, in an async "enqueue"
way, but then who are you to dictate the location on-disk?
 I feel that the current binding doesn't use any significant
features of HTTP that would justify the added complexity of _not_
using HTTP as a transport protocol.
 In your comments, what exactly do you mean by application
semantics? I see these as, for example, that the server will
check and charge my card and that it will send me the new Porshe,
when it receives my purchase order.
 Kind regards,

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Thu, 19 Jul 2001, Mark Baker wrote:

 > Jacek,
 >
 > 7/19/2001 4:32:26 PM, Jacek Kopecky <jacek@idoox.com> wrote:
 >
 > > > >  Now back to reality - we have SOAP/1.1 and a working draft of
 > > > > SOAP Version 1.2 and we started with the HTTP binding modeled as
 > > > > an extension of HTTP. We are considering binding to TCP now.
 > > > >  I can see how one binding could be layered over one protocol
 > > > > while an other binding would extend an other protocol, even though
 > > > > it is a bit of inconsistency.
 > > > >  Anyway, does modeling the HTTP binding as an extension of HTTP
 > > > > bring some significant added value?
 > > >
 > > > I hope so, otherwise all this typing is a big waste of time 8-).
 > >
 > >I'm afraid you understood my last question as
 > >
 > > "does HTTP binding bring some added value?"
 > >
 > >instead of the intended
 > >
 > > "does HTTP binding as an extension of HTTP (as opposed to using
 > >HTTP as a transport protocol) bring some added value?"
 > >
 > >See below as well for I might have misunderstood you here.
 >
 > I don't think I did.
 >
 > > > The application semantics have to be defined somewhere.  TCP doesn't
 > > > have them, so SOAP would either have to be used for RPC, or the
 > > > semantics would have to be implicit by some other means.  Or the binding
 > > > would have to define them.  All of those are, IMO, worse than simply
 > > > reusing the semantics of the application protocol.
 > >
 > >I don't see how HTTP binding specifies application semantics for
 > >SOAP. I don't see how any part of if does.
 >
 > The binding doesn't specify the application semantics, it
 > should use the existing ones of the protocol being bound
 > to.
 >
 > > In my opinion, to SOAP,
 > >HTTP only provides the natural request/response messaging pattern.
 >
 > Yes, that's consistent with the tunnelling view of the binding.
 >
 > >The HTTP requests don't differ except in the SOAP envelope if I'm
 > >doing an RPC or an async notification or some data submission. How
 > >does HTTP define application semantics? (I'm not necessarily
 > >saying it does not, I'm saying I can't see it.)
 >
 > Now we're getting somewhere.  See my next point.
 >
 > > In my view HTTP adds to TCP the following significant things:
 > [snip]
 > > 3) transport methods (GET,POST...) of which SOAP only uses POST
 > >so it could as well be the only method
 >
 > Those aren't transport methods.  If they were, then why are both PUT and POST needed?  They are application
 > methods that do very different things.  Both are equally good at transporting a hypertext document from client to server,
 > but what happens when it arrives is very different.  These are application semantics.
 >
 > Sorry for cutting out so much, but I believe I made my point right there, so didn't want to dilute it.  Let me know if you'd
 > like a response for what I cut out.
 >
 > MB
 >

Received on Thursday, 19 July 2001 17:27:02 UTC