[Oops, so sorry Dave - this was caught by the group spam filter, and I just discovered it. I don t know why I didn t receive a notice. I ll look into it.Message 1 of 35 , Oct 26, 2006View SourceHi Mike,My response was limited to asserting that client-side URI construction is permitted under REST unofficially and under Web Architecture officially. I think this a core part of your position point.As for well-designed-uris, I have long been a champion that we need a "URI Template" aka "URI Query Language" language to make it easier to read/write/rewrite URIs. One reason why folks seem to love the SOAP world is the simplicity of using XML tools for accessing portions of the input, as simple as an XPath or even QName matching. Regex for URIs is far too complicated IMO, let alone something that would add in stuff like QNames into URIs. I've written a fair bit about the various difficulties of mapping QNames to URIs.Cheers,Dave
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Mike Schinkel
Sent: Thursday, October 26, 2006 1:28 AM
Subject: RE: "Lightweight Data Access Services" and Well Designed Urls [rest-discuss]Dave:Since this discussion started at microformats- discuss it is a bit confusing. So I'll ask; was your reply for Etan, or indirectly for me who originated this email thread? At this point I'm terribly confused but I would really like to discuss the merits of my original idea, the one that Etan quickly came to debate me one.
From: rest-discuss@ yahoogroups. com [mailto:rest- discuss@yahoogro ups.com] On Behalf Of Dave Orchard
Sent: Wednesday, October 25, 2006 8:16 PM
To: rest-discuss@ yahoogroups. com
Subject: RE: "Casual Web Services" and Well Designed Urls [rest-discuss]
I don't get the set of URIs that you are concerned with. It seems to be the
set of URIs that are outside of web architecture (because the finding covers
those inside) and have representations that are not hypermedia (which is
kind of funny because by definition such "things" are not in REST). Seems
like a fairly uninteresting set to me.
You seem to have your own internal definition of REST that doesn't map to
one that I'm familiar with. We've established that you think that Roy and
the TAG aren't any kind of authorities wrt REST - because if you did you'd
know that Roy would have a "Roy stern comment"(tm) on any W3C TAG finding
that contradicted his view of REST and he's also contributed to that
finding. FWIW, one of the underlying philosophical aspects of REST is that
resources and their representations change, and that includes REST itself.
The spoon is there if we all agree it's there.
> -----Original Message-----
> From: Etan Wexler [mailto:ewexler@stickdog. com]
> Sent: Wednesday, October 25, 2006 4:37 PM
> To: Dave Orchard; rest-discuss@ yahoogroups. com
> Subject: Re: "Casual Web Services" and Well Designed Urls
> Dave Orchard wrote to rest-discuss:
> > And so we go on [about] the opaqueness of URIs.
> Notwithstanding that
> > all HTML FORM GETs create URIs on the client.
> I wrote in a previous message to Microformats REST
> (<http://microformats .org/discuss/ mail/microformat s-rest/2006-
> October/000299. html>):
> "Hypermedia includes rules of construction where the rules
> find expression in a resource representation of a standard
> content type and where the content type indicates how to
> interpret the rules. HTML forms count."
> If my contributions to the current thread of discussion are
> unclear, please give me a chance to clarify them. If you have
> not read the contributions to the current thread of
> discussion, please do so before evaluating or describing my position.
> > Constructing URIs is absolutely allowed.
> Sometimes, as when a human constructs a URI, REST has no
> bearing on the construction of the URI.
> Sometimes, as when software relies on hypermedia to inform
> and restrict the construction of a URI, REST permits the
> construction of the URI.
> Sometimes, as when software relies on resource
> representations to inform the construction of a URI and those
> resource representations are not hypermedia, REST forbids the
> construction of the URI.
> > Here's an authoritative document:
> > http://www.w3. org/2001/ tag/doc/metaData InURI-31. html
> That document is (or will soon be) authoritative over Web
> architecture, but it is not authoritative over REST.
> The document that is authoritative over REST is
> "Architectural Styles and the Design of Network-based
> Software Architectures"
> (<http://www.ics. uci.edu/~ fielding/ pubs/dissertatio n/top.htm>
> as a start).
> Please do not copy replies to me. I read the mailing lists to
> which I subscribe and will find replies in that way.
... miss. I was referring to web services, not web browsers. ... aspect. ... That new job kept you away for a while? ;-) You were replying to a really oldMessage 35 of 35 , Nov 30, 2006View Source
>> > The next issue you debated with me was whether REST requiredmiss.
>> > hypermedia. I am still unclear as to what hypermedia exactly looks
>> > like (I've seen zero real world examples in anything I've read
>> > online)
>> I would have thought a web browser consuming HTML would be pretty hard to
I was referring to web services, not web browsers.
>> > However, ALL of the examples of web services implementations I haveaspect.
>> > seen that claim to be REST-based DO NOT incorporate a "hypermedia"
>> You might want to look at feed auto-discovery:...That new job kept you away for a while? ;-) You were replying to a really
old message. I've since found many of your articles and I praised them in
later emails as the only ones that I had found that were clear to a
REST-newbie. Also in the past month I've been reading A LOT about REST and
RFCs, and have a much better handle on things.
OTOH, thanks for the links; one of them was new to me.
Also, I'm a huge fan of the URI Template spec.
P.S. One more thing; wouldn't you say that the Atom Feed Autodiscovery and
the OpenSearch, from a web services perspective, fairly trivial with
essentially one operation each? I mean they are not at the level of
something like placing a purchase order or anything.