Here is a suggestion: why not create a REST FAQ on the Group wiki? Stefan, you seem to be a REST expert and I seem to remember that you set up the bibliography section. Why don't you kick it off and let the other RESTafarians like Mark and Jan contribute?
Thanks in advance, Gervas Moderator _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Baker Sent: 08 December 2006 18:56 To: [email protected] Subject: Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards) On 12/8/06, Dave Orchard <[EMAIL PROTECTED] <mailto:orchard%40pacificspirit.com> it.com> wrote: > I think we need a REST FAQ.. Good idea! Hey, look what I found; http://rest. <http://rest.blueoxen.net/cgi-bin/wiki.pl?RestFaq> blueoxen.net/cgi-bin/wiki.pl?RestFaq It's in desperate need of an update though. It's opacity section is particularly lame, although the favicon example is a good one. > For the nth time now, URIs can be opaque or not opaque in REST. REST does not say anything about this. It does talk about the application model being hypermedia though, which constrains the use of URIs in a way which some would call "opaque" (myself included). Like the favicon example in the FAQ, or robots.txt ... or even the "?wsdl" convention that Steve just mentioned. These are not RESTful because they don't respect the hypermedia application model constraint where links need to be explicit. Another name for this practice is "squatting"; http://esw.w3. <http://esw.w3.org/topic/UriSpaceSquatting> org/topic/UriSpaceSquatting > All those that think URIs should be opaque should try to resolve that goal with the goal of having all resources have identifiers in the context of HTML FORMs. Either the client creates URIs based on the FORM or the client doesn't create URIs for the (new) resources, all of this at the control of the server. The point is, of course, that clients shouldn't construct URIs without license from either the publisher of those URIs (e.g. a form), or the URI generic syntax. I'm surprised you didn't mention the TAG's work in this space, Dave, which was just updated this week; http://www.w3. <http://www.w3.org/2001/tag/doc/metaDataInURI-31> org/2001/tag/doc/metaDataInURI-31 Mark.
