Re: Static vs. dynamic aspects of a service description (was Re: HTTP properties

On Apr 29, 2004, at 7:44 AM, Mark Baker wrote:

> I'd like to understand the use case for this (and the recent 
> suggestions
> to describe HTTPS and chunked transfer encoding).  It was my
> understanding that a WSDL document described the static aspects of a 
> Web
> service, as it allowed code to be generated which could assume those
> static things.

I agree that the use case or cases need to be teased out; there a 
couple of different potential angles to this. If it's to describe 
regular Web resources, WSDL is far from an ideal format, IMO.

> So what's the value in, for example, allowing a WSDL document to 
> declare
> "This service accepts gzip encoded documents", when HTTP already does
> that?  Is the idea that declaring it in a WSDL means that it's static
> for all time?  If not, then what's the value add, since if I didn't
> declare that in the WSDL, I could use gzip as long as I wanted, then
> change later?  And if so, why would you want to do that?  Why isn't 
> just
> writing your code to the HTTP specification sufficient?  And how do you
> deal with inconsistencies, since that information is now available in 
> two
> places?

HTTP allows the client to describe acceptable encodings in the 
response, and I would agree that it's best to keep that information in 
HTTP.

However, there is no defined mechanism for the server to describe 
acceptable encodings in the request without an extra round trip, which, 
in POST-heavy uses of Web services, is important to many people.

Expect/continue is probably the most straightforward way to do this in 
current HTTP, but has some problems, both in its design [1] and in 
implementation (it is very poorly supported by many). It also requires 
an extra response message, and a pause on the sender's side (if you 
don't want to call it an extra request, which it effectively is).

One could use a new 4xx status code (or just plain 400) and either a 
new response header, or, at a stretch, the Accept-Encoding header as a 
response header, but none of that is specified behaviour, and requires 
an extra round trip.

OPTIONS has similar problems, assuming that you don't get the WSDL 
through OPTIONS in the first place.

One could argue that getting WSDL is effectively an extra round trip 
anyway, but the problem is that Expect/Continue and Accept-Encoding 
work on a per-resource basis, so it actually encourages people to lump 
more functionality into a single endpoint, which isn't good resource 
modelling. A description format that can enumerate the properties of 
many resources would alleviate this. Also, E/C, at least, doesn't give 
you any way to scope the metadata in time; AE might if you reuse some 
of the caching infrastructure, but it doesn't really have the 
granularity to differentiate between the cacheability of the 
representation and that of resource-specific metadata.

Cheers,

1. http://2002.iwcw.org/papers/18500001.pdf


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Thursday, 29 April 2004 15:07:37 UTC