On Feb 14, 2010, at 2:24 PM, Kevin Duffey wrote:
>
> I thought what the proposed additions to Jersey were trying to do is make it easier for server side developers to return JUST the URIs that can be called based on the context of the current request. If they POST a document (or a form, file, whatever), the response should be one or more URIs that they can use.. such as viewing the posted document, editing it, etc. This is very much like how current web sites work.. I get back a page full of links.. I can click one, and only one of those links to do something next. The browser (client) doesn't modify those links..it displays them. The end user clicks them. As far as I can tell, that is what HATEOAS is all about.. the server does some logic to figure out the specific URIs to return based on the context of the request being processed.. thus allowing the next set of possible operations that can be done.
Yes.
> Maybe I am not fully understanding what you are saying. I think we may need Roy to respond with regards to the issue of the client storing the state. I don't believe browsers store state that is currently on the server?? What am I misunderstanding?
>
Use of the word state is often confusing. There are two separate bits of state but its not always clear which one folks mean:
- Resource state which is managed by the server. This type of state is the kind of stuff you'd often persist in a database. E.g. a list of products, orders and stock levels in a shopping application.
- Application state which should be managed by the client. This is the state of the "conversation" with the server, e.g. if I've selected a couple of things I want to buy and am getting ready to pay, the application state is the list of things I want to buy and a set of instructions for paying (e.g. a credit card form definition).
With this separation a client should be able to save its state for a day/week/month and in the meantime have the server be rebooted, new stock added etc. The client can then rehydrate its state at some later point and still be in position to place the order (though of course the products may now be out of stock or no longer carried).
The opposite of this is use of session state where the server holds the contents of the shopping cart and identifies the current client using, e.g. a cookie. In this case the client doesn't control its own application state and the servers job gets more complicated since it has to worry about persisting sessions, session time out, and session sharing if the application is distributed over more than one server.
Is that any clearer ?
Marc.