posted 16 years ago
One problem I have encountered when designing RESTful interfaces is that of resources with a limited timespan.
It's often said of REST that a GET to the same URL should always return the same data. In many real-world applications this does not hold, though. Some data may only exist for a limited period, or only be available to a particular requester for a limited period, or be archived to a different URL, or whatever. This is a common problem on the web, where millions of links no longer link to what or where they used to.
I'm toying with solving this in one application using some form of "leasing". For example, a GET might return the desired data along with a "best before" expiry date, after which the data will no longer be valid and/or no longer available from that URL.
So far this seems both effective and RESTful. However, in most descriptions of leasing, there is also the option to "renew" a lease by performing some particular operation before the lease expires, to obtain a new expiry date.
My puzzle is how this renew operation might map onto RESTful requests. On the one hand, requesting a new expiry date feels like a GET, but on the other hand it has a side effect of extending the lease and keeping the data available, and side-effects are not very GET-like.
Does anyone have any suggestions on how to map this sort of situation to a RESTful approach?