[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Why REST

• To: xml-dev@l...
• Subject: Re: Re: Why REST
• From: Sean McGrath <sean.mcgrath@p...>
• Date: Mon, 18 Feb 2002 11:33:04 +0000
• In-reply-to: <1013920812.944.166.camel@l...>
• References: <A965T71MKD0YVNLXT53WOLIA874E.3c6f1a65@MChamp><A965T71MKD0YVNLXT53WOLIA874E.3c6f1a65@MChamp>

[Simon St. Laurent]
>... as a location within the space defined by www.amazon.com as
>seen through the perspective of HTTP.  What we find at that location
>varies over time.

Its more than just time - all attributes of the observer (headers + body of 
GET/POST for
example) - effect the resource retrieved. The act of observing in effect 
de-quantizining
the URL. We cannot know the state of a resource without observing it and 
the act
of observing it can change the resource.

The fact that URLs can be and regularly are "hooked" to introduce 
resolution trickery or
abritrary cleverness makes the more abstract layers above URL redundant in 
practice
but perhaps (just perhaps) intellectually useful - like hadrons and other 
abstract
base classes.

URLs are just points in an information space. You can send/recieve information
to/from these points. The effect of such sending/receiving on the information
space is unbounded and unknowable.

Information retrieved from aURL s a function of an unbounded
state space consisting of all information in the request (headers + body) + 
time.

Thats plenty abstract and plenty powerful enough for me.

As for URIs that are not URLs - they make my food repeat on me something 
terrible.
The GET verb is the great leveller of the Web information space. I think it 
should be
applicable to all URIs so that the information space is homogenously 
observable at
a minimum.

If using URI rather than URL looses that homogenous observability, it had 
better
provide significant benefits to make it worthwhile.

Sean
  

• Follow-Ups:
  • Re: Re: Why REST
    • From: John Cowan <cowan@m...>

• References:
  • Re: Re: Why REST
    • From: Mike Champion <mc@x...>
  • Re: Re: Why REST
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: RE: Streaming Transformations for XML
• Next by Date: Restriction of MIXED
• Previous by thread: Re: Re: Why REST
• Next by thread: Re: Re: Why REST
• Index(es):
  • Date
  • Thread