Kevin,
Haven't seen a response to your questions. Let me try. In short, yes, if you're using a client proxy and attempt to carry out an action that is invalid in the current state it will be flagged as an error (an exception will be thrown without accessing the network). If you're not using a client proxy, this check will be done by a server-side filter.
Of course, if multiple clients are accessing the same resource, there may be concurrency issues to deal with (the operation of checking the state of a resource and subsequently carrying out an action is not atomic).
-- Santiago
> In the sample I saw, there is the switch call that based on the order state, returns a subset of links.. and that was easy enough to understand and looks easy enough to work with. However, even tho it may return only two actual links, say get/put, does the proposed framework handle the case where a client may call a different URI or invalid method on a given URI... for example, suppose only a GET comes back for /orders/1... and the client tries calling PUT on it. What will happen? I would guess that the @PUT method handler is called (if it's implemented)... but does the framework actually block that call completely.. or does my @PUT (and all my other method type handlers) have to have some checking code to verify that the call is valid based on the current state?
>
> I ask this because as nice as the switch() code is to return specific links based on the state, I would like to avoid having to put if() checks in every one of my handlers to make sure the call is valid given the state. I suspect tho that this is going to be required, especially given the statelessness of REST. Hence, I don't think there is some sort of cookie mechanism with subsequent calls that can be utilized by the framework itself.. to maintain the state between calls so that the framework can block calls if they are not valid given the state. Did I say state enough?
>
>
>