On Wed, May 13, 2009 at 3:40 PM, Roger Menday <roger.menday@uk.fujitsu.com> wrote:

> I am not feeling comfortable with having a state model which
> will change on the fly, depending what a resource will
> answer. For one thing, it will make user interfaces and
> tools really difficult to design:
>
> - should I add a suspend button, even if it works only sometimes?
> - if it worked once, will it work again?
> - what can I do if it does not work? I want to suspend,
> dammit! ;-)

I don't share your pessimism, but then again, I also think we are
getting our wires crossed. I think there is a lot of help here from
hateoas which does a lot to address your concerns above (??)

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.

The temptation is to assume that infrastructure is a simple problem with a fixed domain but I can assure you this not the case - without allowing for such flexibility each implementor will find themselves having a good chance of running into functions they are not able to expose via the API, or which the API expects but which are not present (for example, if "stop" implicitly results in "destroy" should we offer "stop" at all?).

Like it or not there will be rapid evolution in this space and you only need to look at what weird and wonderful things people like Google and Cisco are doing with hardware to realise that we pretty much don't know what we're talking about today let alone the life of the protocol.

Sam