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?
One thing you could do is make a lease extension an unrequested side effect of GET, a side effect like incrementing a hit counter. Section 9.1.1 of RFC 2616 says:
"Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them."
This would mean that every GET request would extend the lease by some amount of time. A resource would only die out if clients stopped GETting it.
Alternatively, the expiry date is a bit of state of the resource, so you could allow the client to change that state with PUT or overloaded POST to the resource URL. If you used PUT, you'd need to have the client send a proposed expiry date rather than a relative amount of time, to keep PUT idempotent. Of course you could reject any unreasonable dates.