mark nottingham

Very good points.

Also, I have the feeling that “personalisation” with or without cookies is considered harmful in REST, or as you say abusing the Web. Why is it so?

A REST resource can have many representations, so it seems that there is no reason why you can’t have different representations for different users (based on the IP address or HTTP authentication or cookies).

What is the best approach for RESTful personalisation, while preserving cacheability of representations?

Jerome:

Rather than separating a user identifier…

Cookie: userid={USER_ID} /content/foo/

Why not try something like this for personalization…

/content/{USER_ID}/foo/

This way, the pivot for personalization is a part of the URI identifying the content - rather than as a free-floating stateful value maintained somewhere outside a series of HTTP requests. Representational state transfer, and all that.

And I think when we talk about a resource having many representations, that means that the content is basically the same, just offered in different formats or encodings. If content is personalized, that’s not just another representation of the same thing - there’s modified and customized content there, by definition.

Changing the content based on IP address or cookies really damages cacheability and the idea that a GET is idempotent, as I understand it.

I pretty much agree Mark, there are some important tradeoffs in this space. But the problem now is that there’s little in the way of options for developers, and I think Berend’s work provides another option with different tradeoffs, which is good. Yet another one that I think would be of value, would be in placing the credentials - rather than just a token for them - in the cookie.

I came round to pretty much the same conclusion as lm orchard, while playing around with making our document management system talk WebDav.

By placing the user credential inside the URI, it’s saying that the resource is particular to people with certain credentials.

One downside is some freshness is lost, say when user B updates a resource, user A might end up seeing the outdated cached copy of the resource.

The other downside is it doesn’t quite feel right. A resource shouldn’t have to pretend to be multiple resources to different people.

Any reason why HTTP shouldn’t have a special header for kerberos-style tickets? It’s exactly what cookie-based authentication is trying to achieve, and would also be helpful in the case of federated logons.

Re authentication killing caching - this is kind of axiomatic. If you do not want to send a different response to each user, why bother asking people who they are?

Any framework that supports authentication should also support seperating resources that need to protected or personalised (like my inbox at gmail) from resources that dont (like static images or stylesheets).

Anyway, I don’t think you need to make it a case of cookies vs HTTP auth. I think the ideal for a REST framework would be when a protected resource is requested, check for either a Cookie header with a valid session cookie in it, OR a HTTP Auth header with a valid username:password in it. If neither are found, return a 401 response in the header and a HTML login form in the body.

That lets you build a nice intuitive UI for interactive users, but also makes it trivial for to people use curl or XMLHTTP or whatever.

@Mark » If you’re doing personalisation, the URL, not the credentials, should be the key to the personalised content.

Can you explain a little more why that is?

Also, can you point to the best resource you know of that covers caching issues thoroughly and in depth?

I’m not sure if I understand what you’re suggesting as the alternative to killing cacheability with authorization headers.

If your resource is secured, and requires authentication in order to be retrieved, then authorization must be checked before a resource is returned, even if that gets in the way of your caching strategy, no? How does using cookies (or not) really affect that?

Mark,

i disagree with your assertion that personalisation and authentication are orthogonal; If it were the case, then on a random webapp an anonymous user would have access to your personalized representation, without authenticating as being you - i do not know if there are webapps implementing that functionality, but neither i have come across one of them nor i believe there is value there.

On the other side, i support your idea that using only one method is a better solution - at least on most of the cases.

The ideal solution would be a method to mark exactly what parts of a page are not cacheable - perhaps to an html-div level. The problem we are actually dealing with is that an html document is not as fine-grained as we could get. As Jonno says, you can cache images and .css, but you can’t cache the left menu or the header of your documents without caching the rest - well, you may use frames, but hopefully you won’t.

Mark,

Completely on your side when you say that your particular data deserves a new URI. But, as I understand it, if it has another URI then it has been not personalised; it is another view of the resource. That is precisely why it deserves a brand new uri.

A uri is personalised, IMHO, when by means of logging in the same uri has different content among users. That kills cacheability and orthogonality.

That was the point i was trying to make on the previous post. Anyway, if you look carefully, you talked about personalisation and authorization orthogonality, whereas I replied talking about personalisation and AUTHENTICATION orthogonality, thus rendering my previous post fundamentally flawed on its premises. I was talking about something different, so I’m sorry.