Another REST challenge

Here is a second use case, which I think also represents a challenge to 
REST. In this case, not so much that you could not do it is REST, but 
that REST would not appear to `speak to' the use case in a meaningful 
way (i.e., doesn't contribute much)

Imagine that you have a car rental service, owned by Hurtz (H) and a 
punter (P). P wishes to rent a car from H and H wishes to maximize its 
opportunities.

P approaches H, and says "I'd like to hire a car"
H replies, "Where, when and which class?"
P replies "Denver, next week and do you have a convertible?" (I.e., 
doesn't directly reply to H's question, but responds with another 
question)
H replies, "As it happens, we do, for $15/day extra"
P replies "That sounds good"
H says "We notice that you are going to denver in skiing season; there's 
a special on ski racks next week, are you interested?"
P replies "Hey, sure"
<some time later>
P says "I've got an upgrade coupon, can I have an upgrade please?"
H says "Mmmh, sure"

The point behind this use case is that it is in H's interest to be able 
to offer timely deals to P in order to maximize its potential. However, 
it is fairly unlikely that H can predict (at design time) all the 
possible offers and even more unlikely that P can be built to ask for 
ski packages, even though there IS a possibility that P could make use 
of such an offer.

In addition, P doesn't wish to trawl through H's list of car 
specifications, instead it wishes to send a constraint or query to H 
that encapsulates its preferences.

The benefit of this scenario should be obvious, even scary. From a 
business POV, it makes it easier for suppliers to maximize their profits 
by making timely localized business choices that do not require 
everybody (from the W3C on down) to agree beforehand on the range of 
choices. From a customer's POV it makes it easier to integrate 
customer's preferences in transactions.

Frank McCabe

Received on Wednesday, 17 July 2002 17:59:07 UTC