- From: Roy T.Fielding <fielding@gbiv.com>
- Date: Sun, 22 Jul 2007 20:23:59 -0700
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: W3C TAG <www-tag@w3.org>
On Jul 22, 2007, at 9:00 AM, Richard Cyganiak wrote: > I think Roy's abstract model from REST goes something like this: A > resource (these days we should say: information resource) is a > function that maps a request Q received at time t to a > representation R. If this function is the same for two information > resources, then they are the same resource. That last sentence isn't quite right. If the function is the same then they are the same resource from the point of view of all of the other actors within the system. The resource owner may have a different opinion, but that opinion simply isn't observable to those accessing the resource (and therefore irrelevant to the run-time architecture). > So the function can return different representations at different > times, and it can return different representations at the same time > for different requests (content negotiation). > > And it's important to remember that this function is an > implementation detail of the server. We cannot determine the > function by inspecting the resource through its HTTP interface, > because for that we'd have to be able to travel through time. > > This means that only the resource owner can determine if two > information resources are the same. The resource owner can publish assertions about resource equivalence, though even resource owners can't really predict the future. It isn't intended to be a hard and fast rule. The purpose of the definition of resource is to help people understand the relationship between making reference to a thing and later accesses to that thing. Most people just assume that all URIs identify a static file of bits, even when they are doing something that obviously doesn't conform to that mental model (like writing a script that handles an entire URIspace in a programmatic way, or linking to a feed URI). It was very hard to explain to folks that what matters is what the link author intends by the reference, not what the link resolves to at any given moment in time. REST is a model for network-based hypertext systems. That was an intentional limitation, since I couldn't possibly compare the performance impact of the given constraints without a domain upon which to base the comparison. I honestly don't care whether people think of that as the scope of information resource or some other limitation. I was certainly aware of resources that had no representation -- Tim talked about it back in 1994. Those resources simply did not matter to the model since they did not contribute to the Web as hypertext. > I think Roy's work is by far the best and definitive account of the > things we now call information resources. But it does *not* account > for any of the new stuff we're doing with URIs these days. Web > architecture has evolved since Roy wrote his thesis. Unfortunately, > many REST proponents are still stuck in the pre-httpRange-14 past, > and are likely to remain there for a few more years. Thanks, but what is this "stuff we're doing with URIs these days" that is not accounted for within the REST model? The httpRange-14 debate was intense because the original question was wrong -- that HTTP should be limited to addressing documents. We spent several years butting our heads on what was essentially a poorly worded question, and the answer was obvious once the goal of asking the question was considered instead of the question itself. I remember suggesting redirects many times, but it wasn't until I explained how the 303 (see other) code works [which I changed the definition of back in 1995] that we finally had an answer that would satisfy everyone's application. 303 is the RESTful answer -- a way of indicating that the unrepresented resource exists while indirectly continuing the conversation. BTW, I would really appreciate it if people would stop defensively lumping "REST proponents" into some category that assumes that a bunch of individuals speak with one voice. Most REST proponents started out as critics, and each has their own perspective on why. ....Roy
Received on Monday, 23 July 2007 03:24:36 UTC