Question: I'm developing a new experimental web-application framework, and I decided to give RESTful some attention. I've read up on the basics, and feel like I have a pretty good understanding of RESTful as a concept.

I've got a system up and running, using URLs strictly to define 'nouns' in the system and take the 'verbs' from the HTTP request methods. I'm using javascript ajax calls to provide access to the DELETE and PUT methods which HTML forms cannot provide. (I realize these measures aren't strictly required to be RESTful, but it satisfies the 'Uniform Interface' requirement).

The problem comes with stateless-ness and cacheability with authentication. The standard model for user authentication on websites involves a "login" authentication event, after which (if successful) a user is "inside the wall" with a persistent secure session and may see and do things on subsequent requests which unauthenticated users may not. This persistence of authentication seems to break RESTful-ness. Caching and statelessness appear to be broken, because the authenticated user will probably see HTML which is different from that which a non-authenticated user will see for the same request (for instance, there might be a login form in a sidebar for the logged-out user).

Using www-authenticate strategies to authenticate a user only on the requests which require authentication seems to be a step in the right direction, as it doesn't involve the concept of a persistent secure session. However there's still the question of how to portray a "logged in" appearance to the end user in keeping with what we've all come to expect from websites.

So in the current thinking, what's the preferred way to handle authentication and permissioning of a webpage in a strictly RESTful way, while still allowing for logged-in decorations in the HTML?

Answer: 
> 
> This persistence of authentication
>  seems to break RESTful-ness
> 
> 
> 

Instead of authenticating a user, you may think about creating a session. You will be returned a new "Session ID", along with the appropriate HTTP status code (200: OK, 403: Forbidden, etc).

> 
> The user will probably see HTML which is
>  different from that which a
>  non-authenticated user will see for
>  the same request
> 
> 
> 

You will be asking your REST server: "Can you GET me the HTML (or any resource) for this Session ID?". The HTML will be different based on the "Session ID". 

With this method, there is no wall for "persistent secure sessions". You are simply acting on a session. 

The noun (or the resource) would represent the the actual session, if you opt for this method.
Re: Daniel's answer: 

If a session is a transient object that gets quickly deleted, this is not very cachable, as any cache you create would only have a useful lifetime of maybe a day, but also continue to use up space in the cache anyway. 

Wouldn't it be better to create the USER as an object, and authenticate using the digest authentication, (or a cookie if you must). that way, each user gets their own persistant cache instead of a cache that lasts a day and disappears.

This also makes more logical sense to me, since you're making a page look different depending on the USER, (adding 'hello [name]' and such) and the difference between the "logged in" and "logged out" states depends on whether the user is included in the URL. Whether a particular person is granted access to that user specific url depends on whether they can authenticate as that user.