Re: REST example

 Mark,
 your example is a fine use of REST as far as I can see, but 
there is no SOAP there. I think I could see before how such an 
example application could be done, although not so prettily.
 What I wanted is an example where you would use SOAP together
with the current web architecture. 
 It seems to me that taking REST+XML(+RDF) we don't need SOAP at
all. On the other hand, it seems to me that SOAP is a thingie
that does "in the old way" what the above do "in the web way".
 Unless I'm shown the two can be combined simply and naturally, I
won't be persuaded to leave the "tunneling" view, I'm afraid.
 Kind regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 5 Mar 2002, Mark Baker wrote:

 > Jacek,
 > 
 > >  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
 > 
 > response;
 > 
 > 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" />
 >  </Description>
 > </RDF>
 > 
 > 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/">
 >  <departing>
 >   <location>YOW</location>
 >   <date>2002-03-03 15:20 EDT</date>
 >  etc..
 > </itinerary>
 > 
 > 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">
 >   <departs>11:30</departs>
 >   <purchase>http://www.ua.com/ticket-purchase/123456</purchase>
 >  </flight>
 >  <flight id="UA9334">
 >   <departs>12:30</departs>
 >   <purchase>http://www.ua.com/ticket-purchase/123457</purchase>
 >  </flight>
 > </flights>  
 > 
 > 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/">
 >  <number>92384293849234982394</number>
 >  <expiry>2004/11</expiry>
 > </credit-card>
 > 
 > 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/">
 >  <number>23429348234</number>
 >  <uri>http://www.ua.com/reservation/23429348234</uri>
 > </reservation>
 > 
 > and here the agent knows how to check reservations.  To cancel the
 > ticket, it could invoke DELETE on that reservation resource, I
 > suppose.
 > 
 > 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/
 > 
 > MB
 >

Received on Wednesday, 6 March 2002 04:38:38 UTC