Re: Response envelope optional vs. response optional

Yves Lafon writes:

> To be "truly" one way, 202 is the best option as it ensures 
> that the underlying protocol did its job, but without any 
> information from the SOAP stack.

I believe it was Chris Ferris who mentioned some interest in 204.  I'll 
leave it to him to explain what he has in mind.

> In previous discussion, we talkd about the identification of 
> the MEP in use by the originator, GET would map to a response 
> only, while POST would map to the request-response. Having the 
> 202 in here forbid the client to know which MEP is expected 
> (unless there is a tighter coupling, like the application knows
> from a WSDL description what to expect).

FWIW, my proposal assumes pretty much what we've had.  There are two MEPs, 
as there are today, named Req/Resp (or something else if Anish is right) 
and Response-only.  As today, the HTTP binding requires the 'client' to 
choose, and in particular to use Req/Resp for POST and Resp-only for GET. 
So, the 'server' knows the pattern from the WebMethod, as is the case 
today.  The only thing that's different is that we make clear that the 202 
entry in the HTTP binding table for Req/Resp is not an accident, but is in 
fact the embodiment of the optional response envelope that we now 
explicitly discuss in the definition of the Req/Resp pattern.  To do that, 
we should clarify the appropriate table entries.  Nothing else changes in 
the binding, except to make clear that 202 (and maybe 204) is OK to send 
as a response and that it's interpreted as "success with no envelope".  We 
just change the MEP description to make clear that the binding is and has 
been correct (if a bit vague) all along.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 21 December 2005 14:43:20 UTC