Re: FW: LC Comments: Web Method Feature

Mark Baker wrote:
>>Great, I think we are getting somewhere. So, in the context of the HTTP 
>>binding (which is what we are talking about here) you would agree that 
>>the use of GET and POST is not orthogonal to the MEP in use ?
> 
> Right.  But still not non-orthogonal enough to be able to derive the
> method from the MEP. 8-)
>
I agree:

(i) For the request-response MEP, only choice is POST because GET can't 
send request entity body (SOAP message).
(ii) For the response MEP, either GET or POST is possible. The missing 
piece of information is whether the operation is safe or not. If it is 
safe then GET should be used, if not then POST should be used.

So, I would argue that the two pieces of information that are required 
to decide on a suitable HTTP method are the MEP and whether the 
operation is safe.

> 
>>It sounds like you are drawing a distinction between an abstract 
>>conceptual GET operation and the implementation of that operation in 
>>HTTP. Unfortunately both are being labelled with the name 'GET' so it is 
>>difficult to tell which one you are referring to in any given sentence. 
>>If my surmise is correct I would be interested if you would care to 
>>layout the areas of commonality and difference between the two. E.g. 
>>does the conceptual abstract GET share the restrictions of HTTP GET that 
>>the information retrieval must be safe ?
> 
> 
> Yes, the abstract "GET" means exactly what it says in RFC 2616 section
> 9.3.  It's the rest of RFC 2616 that places restrictions on how this
> meaning can be used to exchange messages in a HTTP 1.1 transaction.
> Section 8 describes the bulk of them.
> 
> FWIW, I'm making this distinction only as an aid to explaining my point.
> Maybe it's not working. 8-O
> 
No, it isn't ;-). If they had different labels it might work but using 
the same term to refer to two different but related things is just plain 
confusing.

> 
>>>Sure.  But that only impacts the ability to transfer a SOAP message, not
>>>the pattern with which it is exchanged.
>>>
>>
>>But in the HTTP binding we match MEPs to HTTP methods so the HTTP method 
>>has to be able to support the MEP...
> 
> 
> Yes, but "able to support the MEP" is determined more by the inherrent
> message exchange constraints of HTTP 1.1, than it is by the meaning of
> any given method, IMO.
> 
But we are talking about the HTTP SOAP binding here. That has to take 
into account the "inherrent message exchange constraints of HTTP 1.1".

Regards,
Marc.

-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Tuesday, 9 July 2002 09:54:08 UTC