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

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

Expand Messages
  • Robert Leftwich
    ... Could you perhaps use the concept of permalink (from the blogging world?) where there is a permanent link for the resource, but also alternative views on
    Message 1 of 37 , May 31, 2002
      At 01:35 AM 1/06/2002, bhaugen32 wrote:

      >Robert Leftwich wrote:
      >> A full uri could be
      >> http://www.mytravel.com/person_identifier/trips/planned/JulyHoliday
      >> for a planned but not yet requested (i.e. a sandbox) and
      >> http://www.mytravel.com/person_identifier/trips/requested/XML2002
      >> for a started but not yet fully authorized trip
      >> (i.e. tickets issued) and
      >> http://www.mytravel.com/person_identifier/trips/issued/XML2001
      >> for a trip whose tickets have been issued.
      >I'm very skeptical of changing the URI of a business entity whenever
      >it changes state.

      Could you perhaps use the concept of permalink (from the blogging world?) where there is a permanent link for the resource, but also alternative 'views' on the resources that are state-based? Something like:

      permalinks -


      alternative state-based 'views'


      alternative views would return collections of resources that match the view, using the permalinks i.e. http://www.mytravel.com/person_identifier/trips/planned/ would return :

      <trip permalink='http://www.mytravel.com/person_identifier/trips/Xmas2002/'
      link='http://www.mytravel.com/person_identifier/trips/panned/Xmas2002/' />
      <trip permalink='http://www.mytravel.com/person_identifier/trips/Easter2003/'
      link='http://www.mytravel.com/person_identifier/trips/panned/Easter2003/' />

      Anyone using a state-based link to a trip that is no longer in that state would receive a 301 moved status code with the link to the current state.

      You could still use the state-based uri to manipulate the state as mentioned in the OP.

      Still, I feel a little uneasy about the existence of more than 1 URI for the same resource, but this happens all the time on the web and the 3xx status codes show that this behavior was identified and catered for.

      >I think the URI should be the permanent identity of the business
      >entity and its state should be represented either by data elements or

      Can you give an example of state being represented by hyperlinks?


      PS Anyone else feel that email is definitely NOT the best medium for brainstorming ideas. It's hard to beat a bunch of people locked in a room to sort out a few things :-(
    • 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
        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

        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

        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:


        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

        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.


        The union of REST and capability-based security.
      Your message has been successfully submitted and would be delivered to recipients shortly.