- From: Roy T. Fielding <fielding@apache.org>
- Date: Fri, 25 Jul 2003 01:56:11 -0700
- To: pat hayes <phayes@ihmc.us>
- Cc: "Jonathan Borden" <jonathan@openhealth.org>, www-tag@w3.org
>> A principle of Roy Fielding's REST architecture is that you never >> directly >> operate on the resource. >> >> http://www.ics.uci.edu/~fielding/pubs/dissertation/ >> rest_arch_style.htm . >> see: 5.2. >> >> "resource: the intended conceptual target of a hypertext reference" >> >> Now I realize that discussing whether a remote galaxy might be part >> of an >> information network gets pretty quickly obtuse, by the REST >> definition of >> resource, a resource might indeed be a remote galaxy _identified_ by >> a URI. Please try to keep in mind that the REST architectural *style* is a model for an information retrieval system. It is not a model of the network-of-linked-resources, but of the process for interacting with WWW resources according to instructions found in hypertext. That is why there is a disjoint between the terms used by my dissertation and those used by the mix of people adding text to the webarch document. REST resources are always information resources, not because the resources are information, but because the system is designed to retrieve information associated with any resource identifier. > Well, that document also says (5.2.1.2): > "REST components perform actions on a resource .." > so if the remote galaxy is a resource then Web components can preform > actions on it. REST doesn't care what the resource *is* aside from providing a sameness over time that might be desirable as a link target (the conceptual target). While it is certainly true that we cannot "access" a remote galaxy, it is possible to access a conceptual mapping of information observed from those galaxies. The resource in REST is the conceptual mapping, not the concept. The concept can exist outside the REST-based system and be uniquely identified by the same URI outside the system. Claiming that the URI cannot identify both the conceptual mapping and the real thing outside the information system is equivalent to claiming that your social security number cannot be used to identify anything other than your social security account. REST-based systems use URIs as indirect identifiers, even if they happen to identify the same thing directly. Meanwhile, we can access physical hardware operating in the real world using an http URI, such as the robot arms that manufacture cars. We can act on them via http in the same way, albeit with less fidelity, as we can act on our fingers though signals generated by our brains. We can't say anything about the "realness" of a resource by inspecting the naming scheme of its URI. If I hold up my hand with my index finger extended, people interpreting the visible reflection of light from my finger (its representation as received by their eyes) will comprehend it as representing the number 1. It is still a finger, but when presented consistently in the appropriate contexts it has a different meaning. [*] Now, consider taking a picture of my finger. That picture is a representation -- it doesn't have to be full fidelity to represent either my finger or the number 1, though it does require some metadata to indicate when the picture was taken. Now I assign two URIs, one for the state of my finger and another for the number 1, and bind both within a server to that representation. The semantic requirement that REST has is that if someone applies GET to the first URI they will obtain some representation of my finger, whereas if they apply GET to the second URI they will obtain some representation of the number 1. REST doesn't care how, nor why. If Sesame Street wants to link to my resource representing the number 1, they had better use the second URI. What is important here is not whether the machines can distinguish between those resources, or even if the semantic software can somehow determine their meaning by inspection, but rather that Sesame Street gets what it wants. They can find out what the URI means by asking the authority, or by inspecting the links that other people (especially me) create when referring to the resource using that URI, or by interpreting metadata that is provided by anyone (preferably the authority). Frequently, all this requires is looking at other hypertext anchors and their surrounding text. I hope that helps explain the issues. ....Roy [*] The model presented in REST is based on a theory of human communication, not just a software design. That was not included in my dissertation because it isn't something I wanted to defend.
Received on Friday, 25 July 2003 04:55:51 UTC