RE: HTTP GET requests (was Re: SOAPAction Proposal)

>* Noah Mendelsohn <Noah_Mendelsohn@lotus.com> [2001-05-04 17:16-0400]
>> Just to be clear, although I am indeed intrigued regarding the 
>> possibility
>> of encoding a SOAP request in a URI, probably in conjunction with an
HTTP 
>> GET, it probably would be at best only sometimes be the right thing
to do. 
>>  In other words, an alternate HTTP binding, or maybe an option on the
core 
>> binding.  Also:  I saw a discussion a few weeks ago among some URI
experts 
>> who pointed out that long URI's are somewhere between discouraged and

>> forbidden.  I think that's really too bad based on the (0, 1,
arbitray) 
>> view of limits, but there it is.

Neither HTTP nor URIs of course enforce any rules on how long URIs can
be but implementations often inflict limitations. However, HTTP
applications these days should support in the order of 4-8k URIs which
give some leeway.

>1/ In HTTP, anything which does not have side-effects must use 
>GET.  If I am using a service which tells me the temperature 
>in Tokyo, I  might want to use an HTTP GET request for this 
>request, send my  friends the URI so that they can get the 
>same information, and  get (HTTP) caching for free, since it 
>is likely to be the same 5  minutes later.

Yes, GET in HTTP is special - it is not just another method.

>I am not really sure how we would encode a SOAP request into 
>the query component of the URI without ending with a 2 
>page-long URI, as Noah pointed out. Whether this would be an 
>issue, I don't know. I would appreciate a pointer on the 
>discussion about the length of URIs.

This will also cause problems with XMLQuery

>Note that HTTP POST requests[2] can also be cached:
>
>   Responses to this method are not cacheable, unless the response
>   includes appropriate Cache-Control or Expires header fields.
>   However,

In fact this is wrong and I know confusing. In HTTP, one can only cache
GET (and HEAD as HEAD is a special case of GET with byte ranges).

>In any case, either we find a way to do so, or we will need to 
>talk to Tim about this part of the Web architecture document[1].

I don't think there are any particular problems understanding these
issues but I think we should keep in mind that HTTP was designed to do a
certain thing and do it well - and that is GET.

With SOAP we are talking building on the experience that we have with
HTTP and to use a new framework which is XML rather than RFC 822 style
header fields. As such there will always be conflicts between what one
can do with HTTP and what one can do with SOAP. 

In fact, I would not get too hung up about the HTTP binding - SOAP is
deliberately designed *not* to depend on HTTP and rather than spending
our time trying to retrofit SOAP into HTTP in ways that are not natural,
I would suggest that we keep in mind that there are other ways of
exchanging SOAP messages that are likely to be much better fits.

Henrik