On Wed, May 13, 2009 at 10:08 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Sam Johnston] (May 13 2009):
>
>>> That was exactly the point of introducing both together - given that
>>> most of the innovation is going to happen server side, clients
>>> should be as dumb as possible. That is, it doesn't matter if a new
>>> state comes along after a client has shipped because it will be
>>> advertised as a potential transition (HATEOAS), perhaps even with
>>> the expected target state.
>>
>> I totally agree.
>
> Great. Anyone doesn't agree with the need for [and proposed solution
> offering] flexibility in the state model?

Yes, me, I don't think HATEOAS should be applied in this
context.   But I realise/accept that I maybe the only one
with that opinion - thats ok.  So I'll say it here one last
time, for the record, and then will shut up: "a static
simple state model allows for very simple clients.
Extensions can be defined via substates, or additional
transitions."

I would counterargue that HATEOAS allows for even simpler clients because they don't have to worry about hardwiring even a simple state model. Using HTTP we can even feed them plain $LANG descriptions of what the transitions and targets are - it doesn't get any easier than that and you don't have to worry about updating clients to implement new goodies.

I don't think anyone knows every possible thing that users are going to want to do with the API (I certainly don't have the confidence to say I do anyway) but we may need to revisit this point in the name of interop... Atom categories would be one way to achieve this (e.g. "Cold Reboot" and "Warm Reboot" might go in the "restart" category).

Sam