Is this a valid use case ?

thanks, that clears things up to a large extend.

I like your ideas in the first half (resource lifecycle) and will see if I find the common ground with my thinking – seems very similar (to me now) and maybe we just use the terms differently.

In the second half you are loosing me; I have a hunch why but can’t express that yet.

Thanks,
Jan

(Replies to other comments coming when I have a spare moment).

I don’t expect servers to expose application state: application state isn’t really a concern of the server. Rather, the server manages resource state. The application protocol, and the corresponding application states that can be achieved when executing an instance of that protocol are decomposed at design time into a series of resources, with resource lifecycles and resource states. This allows the server to be stateless with regard to application state.

In other words, a process model can be transformed into one or more resource lifecycle models. Orchestration servers, like BizTalk, manage the process model, and persist application state. This is not what I’m seeking to achieve. Rather, I’m seeking to remodel a process so that it can be described purely in terms of information resource lifecycles, and the rules (known only to the server) that govern the relationships between information resources.

So I’m not trying to expose states that become invalid. Clients can and should include expectations in their requests, which the server asserts against the current state of an information resource, thereby determining whether the intention declared in the received representation is valid in the context of the current state of the resource (determining the current state of a resource may involve the server asserting any rules that relate this resource to others).

The very specific issue on the night was: what can we do to prevent a (bad, naughty) client from going off track, and starting over again – that is, stepping outside the application protocol. Given that we’ve decomposed the application protocol wholly into information resources and resource lifecycles (the server doesn’t maintain a view of the protocol “as such”; it only knows about resources, resource lifecycles and the rules that govern the relationships between resources), the issue then becomes one of ensuring clients interact legitimately with the resources through which the protocol “effect” is realized.

Kind regards

ian

regarding the notion of ‘ephemeral URIs’: We discussed a similar issue over on #rest IRC (see log starting at http://rest.hackyhack.net/2010-02-12.html#254/h254 and next day).

I am having trouble to understand why a server should expose an application state that is only valid for a certain time in the first place? Especially since the state of the application state itself usually evolves over time ( http://www.nordsc.com/blog/?p=358 )

If the client needs to have an expectation about the current state of a resource, I’d rather have the client include that expectation in its request so the server can check it and take appropriate action.

Roy describes this in http://tech.groups.yahoo.com/group/rest-discuss/message/9805

“Think of it instead as a series of individual POST requests that are
building up a combined resource that will eventually be a savings
account when finished. Each of those requests can include parameters
that perform the same role as an ETag — basically, identifying the
client’s view of the current state of the resource. Then, when a
request is repeated or a state-change lost, the server would see
that in the next request and tell the client to refresh its view
of the form before continuing to the next step.”

Could you help me understand what your hypermedia modeling approach is that leads you to exposing states that become invalid?

Thanks,
Jan

I can’t find an exposition of his argument in text, but there is an interview with him at http://herdingcode.com/?p=189 which makes the point.

Ben

For the game it makes sense to me that the server have a user resource and use that to constrain the user to allowed actions, or more flexibly to provide a historical view when the user tries to teleport to an earlier state; instead of re-providing the user with the options available from the earlier state instead disable all but the option they took; you could even hand out the starting url of a completed game so that others could watch your performance (*)

I think minimal constraints should be placed on how resources can be accessed: only those constraints needed to retain the semantics of the application, the more constraints the fewer unintended uses.

Here are some interesting uses: As an employee I put some software items into a basket and hand it over to my boss to approve it, they do so by handing it over to accounts to pay for it. As a lecturer I create a basket of books that I recommended my students read and hand it out to them, each of my students amends their copy of the basket before paying, as a lecturer I also send the basket to the library, they examine their stock, amend the basket and order 10 copies of everything they don’t already have. As a returning lecturer I amend my course and my recommend reading basket and give out the new basket.

(*) Is this effectively creating a set of log resources, i.e. a replacement for log files ?

So if Wyatt Erp requests the URL of the entrance having gone down the steps the server should handle the situation appropriately, perhaps redirecting to the url of the “current” location.

In the example of the basket ordering if someone accessed a URL for an earlier state you would want them to actually be directed to the last phase of ordering they were interacting with because the goal is normally to close the transaction and make the sale.

Time locking the url seems more effort that its worth, particularly as the server already knows what locations are valid as “next” moves when it calculates the “north-south-east-west” directions for the response.