Re: Proposed text for section 1.6.2 and 1.6.3

Mike,

Having clarified in a previous post what I think "engine of application
state" means (and inviting, once again, anyone to correct me), I now
want to reply inline to some of these comments.

> This is a tricky subject, but I think it gets to the core of what we've
been
> arguing about for the last year or so.  In REST, one directly manipulates
> representations of resources that tell somebody/some program to go out and
> ship the book (or whatever).  That's clearly a hypermedia approach to
> setting the application state to "Person X ordered book Y."

So far in this description, I don't see anything that implies hypermedia,
only media.  Hence, I lose the connection to the "engine" topic.

Also, in both architectures (REST and SOA3K), the client effects
remote state changes by sending what is in effect a state specification,
as opposed to transporting itself to where the resource lives and doing
the change itself.

> In
> "non-REST/SOA of the Third Kind / API SOA"  there is presumably some
> software component/object/service/application out there that maintains its
> state, and that state is not exposed as a Web resource, so we invoke some
> code to set the application state.

I'm confused as to what "its state" refers to.  And then I notice that you
are using "application state" to mean what I would call "resource state". I
think this is a subject worth clarifying.

 > So we have "the application itself as
> the engine of application state" as opposed to "hypermedia as the engine
of
> application state."

This is sort of /reductio ad absurdam/ for what seems a misconception
about application state.

>  But it's all pretty metaphysical ... I don't have
> strong feelings that this *needs* to be in the WSA document, except that
so
> much virtual ink has been spilled over the REST vs non-REST issue, and
this
> is the essence of it, so we ought to try to at least put it in
architectural
> perspective.

I think DaveO has made a strong case for why the WSA document
has to account for and acknowledge its relation to REST.  I also think
the "metaphysical" here is what it usually proves to be elsewhere, and
not immune to a little careful observation and analysis.

--Walden

Received on Wednesday, 7 May 2003 18:34:53 UTC