14

According to Roy Fielding (one of the principle authors of the HTTP specification) in his seminal thesis Architectural Styles when discussing REST, he mentions:

[E]ach request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.

By "stored context" he's referring to application state e.g. what the page number for the next page is vs. resource state e.g. any data store, image etc. - which is arguably the whole point of REST.

Is it fair to say that most attempts at pure rest (hereby defined as an implementation that conforms to the above thesis) must fail due to their reliance on storing session data on the server (persistent or otherwise)?

The concept of a session is common - in particular to Web developers - but is it RESTful according to the above definition?

Improve this question
4
  • 2
    I would say according to that definition practically nothing is restful, but how is that definition even reasonably logical? Imagine a "restful" google search- where you have to provide an index of the internet in the request to google for it to search through for you. What? No, saying you can't have a persistence store and be restful would be tantamount to saying restful interfaces are in fact pointless. That doesn't mean we should all start maintaining in-memory sessions and saying it's still good rest design...
    – Jimmy Hoffa
    Oct 5, 2012 at 16:03
  • 3
    I think it should be noted there's a distinction between application state and resource state (the Google index would be resource state, and is perfectly legitimate). I should make that more clear in the question.
    – Matt
    Oct 5, 2012 at 16:04
  • there is such a distinction? Please, define it. :) I've seen people try to define these before, but it get's real fuzzy because they're actually not different. They're both mutable data, the only relevant distinction between one form of state and another is whether it's persistent or not, where the not form means it's usually regenerable which is what makes it different.
    – Jimmy Hoffa
    Oct 5, 2012 at 16:08
  • 1
    I've wondered this myself. Since nobody has ever explained why my application should want a gold "restful" star either I don't really worry about it.
    – psr
    Oct 5, 2012 at 16:27

6 Answers 6

Reset to default
11

I would say yes, session state does make a RESTful app non-RESTful. Trivial example, my sister subscribes to the Wall Street Journal. On a regular basis she will be reading something behind the paywall and decide to send a link (via her own email client, not via WSJ) to a friend who does not have a WSJ account. Click, send, fail. Clearly my sister's experience at that URL is different from her friend's.

Related, but not strictly on-topic: I am in the early design phase of a application designed to support significant research efforts on the net (called quests (think: bookmarks on steroids and LSD)) . The owner of the quest wants to share a particular view of his/her data with someone else, but this view requires a combination of UI state (e.g. which visualizations of what data are showing in which panes) along with appropriate permissions to access the UI and the data displayed. There's a lot of stored-state required for the recipient to get the intended view.

My current solution is to store all of the UI/ACL/whatever info necessary for the view in a separate object and return the URL (probably a UUID) for that object. I believe that accessing the view object could be considered RESTful in the sense that everyone in possession of it gets the same info/experience.

Improve this answer
5
  • 1
    You're view object example is another angle on this. Neat.
    – Matt
    Oct 5, 2012 at 16:36
  • Accepting this as the answer, despite the other great answers, mostly because it answers the question directly and gives a very clear example. Also, the second portion on view objects tipped the scales.
    – Matt
    Oct 5, 2012 at 19:22
  • 2
    If you're saying that wsj site is an example of a non-restful app I would disagree that your example shows that. If the WSJ site is for example relying on data given completely by your sister's client to present her the data, then it is by the definition @Matt gave, RESTful. If it is however relying on temporary in-memory session state it is by the definition Matt gave not RESTful. I merely point this out because the definition Matt gave is based on implementation specifics while REST is better defined by the consumption technique.
    – Jimmy Hoffa
    Oct 5, 2012 at 20:24
  • @JimmyHoffa - My understanding of REST's Constraints is that it is stateless. That seems pretty unambiguous to me.
    – Peter Rowell
    Oct 6, 2012 at 2:52
  • If the WSJ application had no state, the viewable article would have to be sent up by the client. That article could be edited at any time by the site admins, make no mistake it's a piece of the WSJ app's state. I think the distinction being strived for is that it is persistent state, so it will have more guarantees and less management overhead than impersistent state such as sessions, along with simpler atomicity control in transactions on it. This along with the simple consumption model are what people want rest for. (I think)
    – Jimmy Hoffa
    Oct 6, 2012 at 5:26
3

Do server-side sessions violate REST?

They definitely do! When you implement REST, there must be no server-side session, otherwise you have a hybrid RPC/REST solution.

The client must send to a RESTful service all the context necessary to service the request, including the information necessary to authenticate the client, each time a new request is made. The server is free to cache information to make servicing subsequent requests faster, but the cached information must not amount to a server-side session. In other words, the request itself must contain enough information to be processed even in the absence of the cached state.

Improve this answer
2

The most important point of REST is that an URI to a ressource always points to the same ressource. So users can pass around a reference to this ressource and everyone sees the same. This is called Representational State Transfer (REST). If the server keeps state and delivers a different ressource for the same URI, I would say this is not pure REST anymore.

Improve this answer
4
  • that isn't necessarily true that users will see the same thing.. Access can dictate how much any one user gets to see.
    – Erik
    Jul 2, 2014 at 16:52
  • @Erik But the user would state how much they want to see in the request (Including using the Accept Header), so Puckl's answers holds true.
    – Johan
    Oct 27, 2014 at 10:10
  • 1
    @Johan I would return different data for different users, from the same endpoint. Otherwise what's the point of authenticating the user.
    – Erik
    Oct 28, 2014 at 22:30
  • @Erik I would do that too. None the less I believe authentication is outside of the state of the resource, so strictly speaking if the view is affected by the authenticated user then it's no longer RESTful. Maybe if you wanted your RESTful badge you should create multiple "views" of the resource, depending on who is requesting access it authorizes access to only some of the views. So public may get access to /userprofiles/{userID}/publicview and the user gets access to /userprofiles/{userID}/fullprofile and authorized friends get access to /userprofiles/{userID}/friendsview
    – Johan
    Oct 30, 2014 at 10:32
1

Probably depends on what you mean by "session data". Is that a precise term?

Secure communication between two parties often involves the server to generate (and store) a time-limited "access token" which the client has to supply with each request as a manner of authorization. This access token already is what I'd call "session data" - it is stored server-side, time-limited and related to one client (usually his permissions).

I'd be very surprised if this kind of operation was labeled as non-RESTful. OAuth is an example.

I'm not a specialist and I'm not very confident here; I'm just sharing my insights hoping they prove helpful.

Improve this answer
1

What Fielding meant by that statement is that the application server hosting the REST API does not associate ambient state with a request by some sort of behind the scenes mechanism. Consider the difference between an application server and a database server. The REST constraint is that the application server should be stateless. However, the application server can delegate requests for resource state to the database server based on information which is part of the request, such as a user/password combination in the Authorization header or the Uri itself. After all, REST is based on the client/server model.

Improve this answer
0

Sessions are basically used to add state to stateless, RESTful applications. So formally, this makes your RESTful application stateful, however having the server keep state makes your life a little easier, since you don't have to pass all the data back and forth on each request/response.

Sessions, and more generally state, lets you avoid this, and this has some positive benefits in performance (less data transfered) and security (less data available to tamper with).

So while it officially violates part of the definition of REST, it's so useful that it's rare to see RESTful applications that don't use state via sessions.

Improve this answer
2
  • I disagree. You have a shopping site that lets you filter by brand, color and size. Traditional Web 1.0 websites would handle this with some checkboxes, a server-side session, and POST. If I want to share the link to example.org/shirts, people won't see that I selected Medium, Black and Roots. (This also causes the ugly "you are rePOSTing data" message when you click back.) But if I share the link to (e.g.) example.org/shirts/medium-black-roots, everyone has the same representation. All necessary state information is in the URL (or the POST body if necessary, but you can't share that).
    – Jesse Buchanan
    Oct 5, 2012 at 18:19
  • ...RESTful may not be a fit for everything. Is your hypothetical application resource oriented (a shopping site certainly is!)? Perhaps it might not be a fit for an RIA, with a lot of state, which is not resource oriented. I can't think of any good examples to be honest.
    – Jesse Buchanan
    Oct 5, 2012 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.