Re: Issue 5; GET vs GetLastTradePrice

Mike,
>
> Remember that this is a "reference architecture" more  than an actual
> architecture.  The purpose is more to a) identify the key architectural
> components, b) describe various relationships among them that one sees in
> the real world of web services, and c) [maybe] provide some guidance as to
> best practices.  Clearly c) is not something we've really addressed yet,
> hence the lack of SHOULD, MUST, etc.  (I for one doubt if there will be
any
> MUSTs in the eventual document...).  The ultimate hope is more that the
> various web services stacks will line up with one another (horizontally
and
> vertically, so to speak) than to prescribe the One True Web Services
Stack.

I don't see why a "reference architecture" should be somehow less than
an "actual architecture".  Reference implementations that I'm aware of are
full implementations, and they are understood to be representative of
acceptable solutions, but not exclusive in that status.  What's different
here?
The decision to have an "architecture" with no bones...I don't know.

I think REST could be proposed as *a* reference architecture for web
services, and run "through the mill" in that role to see if it's sufficient.
However,
I don't see how that could be done without a web services 'reference
requirement',
which I don't think exists.*  I imagine Mark Baker has already proposed
this,
or something like it, but I don't know the details.

* The "web services architecture requirement" is definitly *not* one.

Walden

Received on Friday, 3 January 2003 20:17:13 UTC