38

I guess this question will sound familiar, but I am yet another programmer baffled by REST.

I have a traditional web application which goes from StateA to StateB and so on. If the user goes to (URL of) StateB, I want to make sure that he has visited StateA before. Traditionally, I do this using session state.

Since session state is not allowed in REST, how do I achieve this?

Jeankowkow
  • 814
  • 13
  • 33
user317050
  • 383
  • 1
  • 4
  • 4

1 Answers1

54

There are 2 REST answers to this, depending on what specifically you are trying to do.

If you are truly trying to manage request-based state (such as when a user is working through a multi-screen wizard or some other navigation-based workflow), then the REST answer is that state should be sent back-and-forth with each request/response (using something like a hidden text field, a query string, or POST data stored in a form). This is an implementation of Martin Fowler's "Client State" design pattern (detailed in full in his book, Patterns of Enterprise Application Architecture; see here for a reference).

If you are, on the other hand, trying to manage some sort of new object on the server--such as a shopping cart--then the REST answer is that you are actually creating a new entity that can be accessed like any other by a direct URL. Whether or not you store this new entity in a database or in application memory (like a traditional Session object) is up to you, but, either way, the new object is less about "state" on the server and more about creating a new entity for the user to interact with.

KP Taylor
  • 2,100
  • 1
  • 17
  • 15
  • 5
    Just one additional point. If you take the "new object on the server" approach then that should be treated as a first class resource and should have an identifying url. – Darrel Miller Apr 15 '10 at 03:35
  • 1
    Trying to grok REST myself... I'm curious: is "first class" a technical term in this context? – keithjgrant Apr 15 '10 at 17:48
  • @keithjgrant I don't know that I would say it is a "technical term" --and it certainly is not specific to REST--but it is a commonly used way of describing any core "object" of a particular technology, programming language, etc., and it connotates that the "first class" object gets special treatement in the technology. – KP Taylor Apr 16 '10 at 13:32
  • @keithjgrant ...continued... For examples: (1) People say that functions are "first class" citizens in JavaScript, because they are more than just subroutines; they are actually "objects" unto themselves (2) F# (a new programming language from Microsoft) is being described as a "first class citizen" of Visual Studio, meaning it is a fully supported programming language in the IDE (3) In Java 1.5 and later, Enums are considered to be "first class citizens" because they are actually supported as a dedicated, specific language construct; prior to Java 1.5, there was no Java "enum" structure. – KP Taylor Apr 16 '10 at 13:33
  • 4
    @Darrel\ Miller I think dogmatic REST would also require URLs for the multi-page wizard. Starting the wizard would create a new resource, with a new resource created for each page, the response of each including a "next" link. You could impose a constraint that all "page resources" had to be created before the "final resource"; this could be done implicitly, with URLs like `1/2/3/submit`. This seems a bit silly, because it's recreating session state, just with URLs. One advantage is the session couldn't time out if the URLs are permalinks. You could bookmark it to complete later. – 13ren Dec 14 '11 at 06:12
  • 5
    Interesting viewpoint. Where is the border line between "state" (to be transferred forth and back) and "resource" (to be assigned a URI)? Is it about the "concreteness", like "a bunch of navigational info is a state, but anything which looks more like an entity or container or object is a resource"? Or is it more about life time? or scope? – Christian Gosch Mar 10 '15 at 15:27
  • 1
    It's worth noting that P of EAA's *Client State* has drawbacks: "if the client fails all is lost, [...] with large amounts of data the issues of where to store the data and the time cost of transferring everything with every request become prohibitive, [...] any data sent to the client is vulnerable to being looked at and altered, [...] don’t assume that what got sent out is the same as what gets sent back. Any data coming back will need to be completely revalidated." – Fuhrmanator Jun 26 '15 at 20:25
  • 5
    @ChristianGosch One thing that seems to distinguish those two (to me, anyway) is session persistence. That is, if a client were to fail (or log out), what would be acceptable to lose? That which is lost would be in the application state. Anything you want to keep in case the client fails (or logs out) would have to be stored in resources. Amazon's shopping cart is an example. – Fuhrmanator Jun 26 '15 at 23:48
  • @Fuhrmanator Interesting point: Amazons Shopping Cart is a permament resource in that it is always existent somehow, even in an unauthenticated navigational state. You can even take it with you into authenticated state. -- In some usual scenarios there is the concept of a "not yet complete" ressource which should "not yet" be persisted because of validation issues. (Amazons Shopping Cart is always valid due to the available operations, so that is a simplistic case; complex offical application forms are not that simple to manage.) – Christian Gosch Jun 29 '15 at 07:02
  • @Fuhrmanator But in a REST application such resources should be persisted anyway, just to have them accessible as a resource -- they are just not yet member of the "validated crowd". Up to now I would have modeled such things as part of the session state, but however if they are treated as "first class resources, just not yet fully valid", session state can be reduced to navigational state, including IDs of currently involved ressources. This can unburden transfer data volume. As any other resource, "not yet valid resources" may be assigned lifetime conditions, like "is gc-ed after X h/d/w/m". – Christian Gosch Jun 29 '15 at 07:03
  • @Fuhrmanator These resources however must be persisted on a permanent storage to have them transparently at hand even in case of a disaster recovery -- or they are no first-class resources. – Christian Gosch Jun 29 '15 at 07:04