Re: [rest-discuss] Re: REST and travel agents revisited
- At 01:35 AM 1/06/2002, bhaugen32 wrote:
>Robert Leftwich wrote: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:
>> A full uri could be
>> for a planned but not yet requested (i.e. a sandbox) and
>> for a started but not yet fully authorized trip
>> (i.e. tickets issued) and
>> for a trip whose tickets have been issued.
>I'm very skeptical of changing the URI of a business entity whenever
>it changes state.
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 :
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 businessCan you give an example of state being represented by hyperlinks?
>entity and its state should be represented either by data elements or
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 :-(
- On Tue March 2 2004 01:22 am, Tony Butterfield wrote:
> However IMHO there are a large number of processing problems that canI agree.
> easily solved by scripting services (behind REST interfaces)
> together into pipelines, as described by Josh, without resortingI think I understand what you're trying to say here, but you are
> to coupling your XML to objects. If you can do this you save
> yourself a lot of work, particularly when the system evolves.
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
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.