Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] REST and travel agents revisited

Expand Messages
  • S. Mike Dierken
    ... From: Robert Leftwich ... hypertext wiki page along with the comment No attempts to RESTify this example have been reported
    Message 1 of 37 , Jun 1, 2002
    • 0 Attachment
      ----- Original Message -----
      From: "Robert Leftwich" <robert@...>


      > Bob's adding of the travel agent scenario to the 'State machine as
      hypertext' wiki page along with the comment 'No attempts to RESTify this
      example have been reported' prompted me to try out my REST skills - be
      warned, the training wheels are still on:-)
      >
      > The resources modelled are similar to those identified in the original
      document:
      >
      > TripIdentifier
      > Participants
      > Participant1
      > Participant2
      > ....
      > ParticipantN
      > Journey
      > Stage1
      > Stage2
      > ....
      > StageN
      >
      If I'm reading this right, it sounds like you are making each item a full
      resource.
      To me, the data called out in the original document (appended at the end of
      the message) don't necessarily need to be full URI resources.
      I don't see the URIs, their structure or nesting as all that important.
      In the nested text shown above, the Participant1 could be an independent
      entity that is merely referenced by the trip, rather than being
      'subordinate' to the trip resource.

      Here's how I would do it:
      The information types seem to be 'traveler', 'trip', 'stage', 'participant',
      etc.
      I'd start with a coarse-grained resource like 'trip' and expand out into
      'traveler' or 'participant' if necessary.
      Within, I'd have an XML blob with details and any useful links.

      The resources I generated in walking through this are:
      -- submit a new trip --
      http://services.travelagents.com/trips/
      -- new trip that was created --
      http://services.travelagents.com/trips/0173/
      -- callbacks for airline to confirm reservations --
      http://services.travelagents.com/trips/0173/airline/ack/
      http://services.travelagents.com/trips/0173/airline/status/
      -- submit new reservations --
      http://services.airliner.com/reservations/
      -- new reservation that was created --
      http://reservations.airliner.com/agents/travelagents.com/res-0029/

      Note - the URIs do /not/ have to be related textually - the URI of the new
      reservation at the airline is even on a different host for example. The
      connection between all these is through HTTP headers, or they could also be
      done via href's inside some XML.


      -- step one --
      The overall flow of this example is as follows: A traveler will plan her
      trip
      by specifying the various stages of his overall journey and all of its
      participants. For each of the stages, the traveler specifies the location
      that
      she wants to visit as well as the date when she wants to begin and the date
      when she wants to end the particular stay. When the traveler is finished
      with
      this, she sends this information together with the list of all participants
      of
      the trip as well as the information about the credit card to be charged for
      the
      ordered tickets to the travel agent.

      == Create a new trip ===
      POST http://services.travelagents.com/trips/ HTTP/1.1
      Content-Type: text/xml
      Content-Model: TripSpecification

      <trip>
      <stage>
      <location>maui</location>
      <start>immediately</start>
      <finish>never</finish>
      </stage>
      <participant>
      <name>Mike</name>
      </participant>
      <payment>VISA</payment>
      <recipient>mdierken@...</recipient>
      </trip>

      == Acknowledgement of submission (with location of trip) ==
      HTTP/1.1 202 Accepted
      Location: http://services.travelagents.com/trips/0173/


      -- step two --
      The credit card information has been passed when the business process was
      instantiated.
      Next, the traveler will await the submission of the electronic tickets as
      well as the final itinerary
      for the trip.

      -- step three --
      When the agent receives the traveler's trip order, he will
      determine the legs for each of the stages, which includes an initial seat
      reservation for each of the participants as well as the rate chosen.
      To actually make the corresponding ticket orders the agent submits these
      legs together with the information about the credit card to be charged to
      the
      airline company.

      == Create new reservations at airline ===
      POST http://services.airliner.com/reservations/ HTTP/1.1
      Reply-To: http://services.travelagents.com/trips/0173/airline/ack/
      Status-To: http://services.travelagents.com/trips/0173/airline/status/
      Content-Type: text/xml
      Content-Model: ReservationRequest
      Authenticiation: Basic [travelagents:password]

      <reservation>
      <!-- URI of secure payment verification callback - the airlines have to
      auth to get in -->

      <payment>http://services.travelagents.com/payment/verification/xyz/</payment
      >
      <recipient>mdierken@...</recipient>
      <leg>
      <flight>UA-1024</flight>
      <seat>33A</seat>
      <rate>$12.00</rate>
      </leg>
      <leg>
      <flight>NW-832</flight>
      <seat>22B</seat>
      <rate>$12.00</rate>
      </leg>
      </reservation>

      == Acknowledgement of submission (with location of reservation) ==
      HTTP/1.1 202 Accepted
      Location: http://reservations.airliner.com/agents/travelagents.com/res-0029/

      -- step four --
      When the airline receives the ticket order submitted by the agent, the
      requested seats will be checked and if available assigned to the
      corresponding
      participants. After that, the credit card will be charged, and the updated
      leg
      information is sent back to the agent as confirmation of the flights.

      -- step five --
      After that, the airline sends the electronic tickets by e-mail to the
      traveler.
      Information about the recipient of the tickets has been specified by the
      traveler when instantiating the trip order process and this information is
      passed to the agent as well as to the airline.

      -- step six --
      Then, the agent will wait for the confirmation of the flights, which
      especially includes the actual seats reserved for each of the participants.
      This information is completed into an itinerary, which is then sent to the
      traveler.

      == Acknowledge new reservation at airline ===
      POST http://services.travelagents.com/trips/0173/airline/ack/ HTTP/1.1
      Content-Type: text/xml
      Content-Model: ReservationConfirmation
      Authenticiation: Basic [airliner:password]

      <reservation>
      <leg>
      <flight>UA-1024</flight>
      <seat>33A</seat>
      <rate>$923.00</rate>
      </leg>
      <leg>
      <flight>NW-832</flight>
      <seat>22B</seat>
      <rate>$923.00</rate>
      </leg>
      </reservation>

      == Confirm receipt of reservation info ==
      HTTP/1.1 200 OK


      --- scenario from IBM's WS Flow Language document ---
      "The overall flow of this example is as follows: A traveler will plan her
      trip
      by specifying the various stages of his overall journey and all of its
      participants. For each of the stages, the traveler specifies the location
      that
      she wants to visit as well as the date when she wants to begin and the date
      when she wants to end the particular stay. When the traveler is finished
      with
      this, she sends this information together with the list of all participants
      of
      the trip as well as the information about the credit card to be charged for
      the
      ordered tickets to the travel agent. The credit card information has been
      passed when the business process was instantiated. Next, the traveler will
      await the submission of the electronic tickets as well as the final
      itinerary
      for the trip. When the agent receives the traveler's trip order, he will
      determine the legs for each of the stages, which includes an initial seat
      reservation for each of the participants as well as the rate chosen. To
      actuall
      y make the corresponding ticket orders the agent submits these legs together
      with the information about the credit card to be charged to the airline
      company. Then, the agent will wait for the confirmation of the flights,
      which
      especially includes the actual seats reserved for each of the participants.
      This information is completed into an itinerary, which is then sent to the
      traveler.

      When the airline receives the ticket order submitted by the agent, the
      requested seats will be checked and if available assigned to the
      corresponding
      participants. After that, the credit card will be charged, and the updated
      leg
      information is sent back to the agent as confirmation of the flights. After
      that, the airline sends the electronic tickets by e-mail to the traveler.
      Information about the recipient of the tickets has been specified by the
      traveler when instantiating the trip order process and this information is
      passed to the agent as well as to the airline."
    • Tyler Close
      ... I agree. ... I think I understand what you re trying to say here, but you are misusing the term coupling . I think you re saying that many processing
      Message 37 of 37 , Mar 5, 2004
      • 0 Attachment
        On Tue March 2 2004 01:22 am, Tony Butterfield wrote:
        > However IMHO there are a large number of processing problems that can
        > easily solved by scripting services (behind REST interfaces)

        I agree.

        > together into pipelines, as described by Josh, without resorting
        > to coupling your XML to objects. If you can do this you save
        > yourself a lot of work, particularly when the system evolves.

        I think I understand what you're trying to say here, but you are
        misusing the term 'coupling'.

        I think you're saying that many processing tasks can be
        accomplished without using an OOP environment, and that doing so
        can often be a good design. I agree. In fact, I designed the
        Waterken Webizer <http://www.waterken.com/dev/SQL/> based on this
        premise.

        It's interesting to note that the XML interface used by the
        Webizer is the same as that used by the XML to Java mapping. This
        property comes from the fact that the XML interface is designed to
        be loosely coupled to the AST.

        Many people seem to misunderstand what 'coupling' is. A piece of
        code, or data, is coupled to something if it uses that something.
        The coupling is 'loose' if there are many possible substitutes for
        that something. Otherwise, the coupling is tight.

        When I demonstrate an XML to Java binding for an interface, I am
        demonstrating loose coupling. The interface is loosely coupled to
        the AST used to represent it. The examples in the Waterken Message
        Tutorial <http://www.waterken.com/dev/Message/Tutorial/> show
        automated transformation between the XML AST and the Java AST.
        These ASTs have become substitutes for each other. That's loose
        coupling.

        The flipside of this argument is that not having an XML to Java
        binding is a demonstration of tight coupling. The interface is
        tightly coupled to the XML AST, because there are no substitutes
        for the XML AST.

        Taking this argument further, I claim that data represented in the
        Waterken Doc Model <http://www.waterken.com/dev/Doc/Model/> is
        more loosely coupled than the XML documents used in Josh's
        examples. This loose coupling comes from the fact that the Doc
        Model was designed to support mapping between many different ASTs.
        This makes it easy to build mappings into a wide variety of
        execution environments.

        Take a look at the grammar for the Doc Model:

        http://www.waterken.com/dev/Doc/Model/#Grammar

        Notice how simple this grammar is compared to the XML infoset,
        Java Serialization Streams, etc. This simplicity creates loose
        coupling by making it possible to represent the data using any AST
        whose grammar is a superset of the Doc Model grammar. The
        complexity of the XML infoset grammar precludes this kind of
        mapping.

        In general, I've read a lot of nonsense about 'coupling'. I hope
        this email gives people an objective basis on which to reason
        about coupling. When people claim loose coupling, ask them to list
        the available substitutes. When people accuse tight coupling, show
        them the list of available substitutes.

        Tyler


        --
        The union of REST and capability-based security.
        http://www.waterken.com/dev/Web/
      Your message has been successfully submitted and would be delivered to recipients shortly.