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

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 16:48:25 UTC