Win a copy of Penetration Testing Basics this week in the Security forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

time spans, REST and leasing

Frank Carver
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
Leonard Richardson
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Those are my two thoughts.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic