WSA constraints

I'm going to try a different tact ...

On Tue, Dec 17, 2002 at 04:24:19PM -0700, Champion, Mike wrote:
> I would be very happy to see a section of the WSA document explaining the
> REST position on coordination/reliability and pointing out the situations in
> which it is likely to be most appropriate.  I'm not interested in another
> "All you need is REST ... REST is all you need" permathread, however. The
> WSA will (presumably) support REST principles as a MAY, but it will not
> insist on them as a MUST.      

This reminds me that I should try again to extract the architectural
constraints of Web services.  I tried before, and some useful discussion
emerged, but it didn't get very far[1].  Plus, the WSA document doesn't
reflect it.

If we say that some of REST's constraints are optional, then we're
saying that the properties those constraints induce are only available
in the "sub-architecture" where those constraints are used ... except
where additional Web services constraints can also induce those same
properties.  Sound reasonable?  We should be able to go through our
requirements to ensure that the properties induced by the chosen
architectural constraints are sufficient to meet the requirements.

For example, there's an implicit requirement that Web services will work
between companies, which requires the property of "visibility" (unlike
working within companies, which doesn't).  We need to identify which
constraints of the WSA induce this property.

> So, is there some reasonably non-doctrinaire language to describe *how* GET,
> PUT, POST, and DELETE *can* provide a sufficient coordination language you
> wish to propose?  

Examples would be the easiest and least controversial way to do this.
But I'd like to defer this until we've documented some constraints.

 [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0083

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Wednesday, 18 December 2002 09:46:03 UTC