W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

REST example

From: Mark Baker <distobj@acm.org>
Date: Tue, 5 Mar 2002 22:02:41 -0500 (EST)
Message-Id: <200203060302.WAA11759@markbaker.ca>
To: jacek@systinet.com (Jacek Kopecky)
Cc: xml-dist-app@w3.org

>  Mark,
>  you admit that it's easy to think that the web architecture is
> only good for "serving web pages", and therefore not applicable
> to bigger "e-business" tasks (or indeed, any distributed task or
> computation); that's almost exactly what I think. 
>  You say that the current web architecture is a big leap, and I
> don't oppose this, it's just that not many people have made the
> leap yet. Like myself.
>  I think it will be helpful if you describe on a real scenario 
> (say reservation and payment of plane tickets) how you'd do it 
> using SOAP _and_ the current web architecture. 

Sure, I'd be happy to.  I try to use examples whenever I can, and I came
up with one last year that I sent to the group[1], though it's obviously
not very "e-business"-y.  It also isn't machine processable, as it
requires a human to understand some things (such as what to expect when
a vCard is POSTed to another vCard).

For airline ticket reservations, as with any problem, you first have to
start by modelling your resources.  In this case, I'd have the following
types of resources;

- credit card
- itinerary
- flight/flights
- reservation

Without any human intervention, we have to assume that we have a piece
of software with knowledge about my flight info (from/to, when, return,
etc..), the price I'm willing to pay, and my credit card info.  This is
typically called an "agent".

Assuming my agent knows to start at United Airlines, it could do this;

GET / HTTP/1.1
Host: www.ua.com
Accept: application/rdf+xml


HTTP/1.1 200 Ok
Content-Type: application/rdf+xml
[blank line]
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 <Description about="http://www.ua.com/ticket-purchase/">
  <rdf:type resource="http://www.airline-standards-r-us.org/TicketPurchaser" />

so at this point my agent knows that http://www.ua.com/ticket-purchase
is a TicketPurchaser, which it knows (it's hardcoded) is a container that
accepts an itinerary.  So next it does this;

POST /ticket-purchase/ HTTP/1.1
Host: www.ua.com
Content-Type: application/xml
[blank line]
<itinerary xmlns="http://www.airline-standards-r-us.org/foo/">
  <date>2002-03-03 15:20 EDT</date>

which yields a response of;

HTTP/1.1 200 Ok
Content-Type: application/xml
[blank line]
<flights xmlns="http://www.airline-standards-r-us.org/bar/">
 <flight id="UA9333">
 <flight id="UA9334">

this response presents the agent with information about each flight
matching my itinerary with a URI for each.

So the agent either asks me if I want to leave at 11:30 or 12:30,
or picks one by itself.  So assuming we wanted the 11:30 departure,
and that the agent knows that the "purchase" element means that the
URI identifies a resource which accepts credit cards, the next step
would be;

POST /ticket-purchase/123457 HTTP/1.1
Host: www.ua.com
Content-Type: application/xml
[blank line]
<credit-card xmlns="http://credit-card-standards.org/foo/">

and the response to that is;

HTTP/1.1 200 Ok
Content-Type: application/xml
Location: http://www.ua.com/confirm/23429348234
[blank line]
<reservation xmlns="http://www.airline-standards-r-us.org/baz/">

and here the agent knows how to check reservations.  To cancel the
ticket, it could invoke DELETE on that reservation resource, I

Anyhow, hopefully you get the idea.  That I used XML and not RDF
(except to start) means that the agent is less general (it can only
buy plane tickets, not DVDs, etc..), but at least it makes for a
reasonably easy to understand example (I hope).

>  As I see it, either we want SOAP as it stands (as a messaging
> protocol), in which case we either tunnel through HTTP (and any
> other application protocol) or we ditch the so called application
> protocol bindings altogether; or we want the web architecture as
> it stands, in which case we'll probably need to redefine SOAP and
> maybe tie it to HTTP completely.

That wouldn't be necessary.  It's still a good idea that SOAP is able
to be bound to different application protocols.  Besides, we've done the
work already.

>  I'm not opposed to being enlightened, but sometimes I do need to 
> see a real scenario in the new paradigm before I see that the 
> paradigm can be used in such class of scenarios.

That's the case for many people.  I hope my example was helpful.

 [1] http://www.markbaker.ca/2001/07/SoapUses/

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Tuesday, 5 March 2002 21:58:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:47 UTC