TAP Implementation issues (cont'd): UWS

[Tom McGlynn]

[This previous discussion got truncated on the grid list when
I did a reply rather than a reply all.  Here's where Guy and I ended 
up... TMcG]

Guy Rixon wrote:
> On 3 Nov 2009, at 15:57, Tom McGlynn wrote:
> 
>> We know that caching does happen and unless we can point out why our  
>> services are immune, then I think the standard needs to say  
>> something like:
>>   Services are required to ensure that caching is not enabled for  
>> GET requests.  [And ideally a sentence or two that indicates how  
>> that might be done.]
> 
> Would you care to suggest the text for this?
> 
Something like

Since the UWS resources are dynamic, servers must ensure that caching is
disabled for GET requests.  If this is not already handled by the
underlying server side software a provider might specify an expiration
header in the past (the date string 0 is always treated as being in the
past so "EXPIRES: 0" might be used).  Another alternative is to specify
a "Cache-Control: no-cache" header.

might do but I'd prefer to have it vetted by an HTTP expert.

> I'm not against putting in this stipulation. I do think that web  
> servers in general get the caching right for dynamic content and that  
> we shouldn't panic about this.
> 
> 
>> I've thought a bit more about why I dislike the dichotomy of POST's  
>> and GETs.  It's not especially that is simpler.  It's that we're  
>> splitting the semantics of the request into two pieces.  Some bits  
>> we encode in how we make the request, and other bits in the request  
>> content.  The REST approach is all about using the different request  
>> types to convey meaning.  I prefer an approach where the semantics  
>> are handled consistently at one level of the interface and we have  
>> minimal entanglement between the HTTP protocol and the system being  
>> built over it.  That's definitely not REST -- which I think I'm  
>> slowly beginning to understand if not appreciate.
> 
> Well, we could go back SOAP, of course. That separates the transport  
> from the application nicely. It's a magic box that does everything on  
> one URL. In the process, it loses most of the benefits of HTTP, like  
> different MIME types for different responses, but maybe you'd consider  
> that acceptable if if reduces things to one HTTP verb. (Unfortunately  
> that verb is POST; but at least there's only one.)
> 
> Of course, UWS was originally a SOAPy protocol, but then people voted  
> massively for a RESTful binding.
> 

I've never understood what real advantage either these had over a CGI
like binding but I'm quite the fuddy duddy on this since it's so 20th
century... Still if the only alternative is SOAP I'll take REST....

	Tom