• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

time spans, REST and leasing

 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic