On Mon, Nov 23, 2009 at 1:01 AM, Peter Ansell <ansell.pe...@gmail.com> wrote: > The issue with requiring people to direct requests at the URI for the > Resource X at time T is that the circular linking issue I described > previously comes into play because people need to pre-engineer their > URI's to be compatible with a temporal dimension.
I would recommend the use of a query parameter. > If the user didn't > know exactly what time scales were used by the server they would > either need to follow a roughly drawn up convention, such as > /YYYY/MM/DD/meaningfulresourcename, or they would have to find an > index somewhere, neither of which are as promising for the future of > the web as having the ability to add another header to provide the > desired behaviour IMO. I'm not sure what criteria you're basing that evaluation on, but IME it's far simpler to deploy a new relation type than a new HTTP header. Headers are largely opaque to Web developers. > The documentation of the Vary header [1] seems to leave the situation > open as to whether the server needs to be concerned about which or any > Headers dictate which resource representation is to be returned. > Caching in the context of HTTP/1.1 may have been designed to > temporary, but I see no particular reason why a temporal Accept-* > header, together with the possibility of its addition to Vary, > couldn't be used on the absolute time dimension. It seems much cleaner > than adding an extra command to HTTP, or requiring some other non-HTTP > mechanism altogether. The extra header would never stop a server from > returning the current version if it doesn't recognise the header, or > it doesn't keep a version history, so it should be completely > backwards compatible. Yes, Vary should, in theory, be used for this purpose. Unfortunately, in practice, due to a bug in IE, it has the effect of disabling caching in the browser and so you don't see it used very much, at least not for browser based applications; http://www.ilikespam.com/blog/internet-explorer-meets-the-vary-header Mark.