First, We Have To Talk About Resources
Information resources relate identifiers to representations.
An information resource is a relation between one or more identifiers and one or more representations.
- The identifier picks out the resource. URLs are identifiers that also serve to locate the resource on the network.
- The representation depicts the resource; it is the literal sequence of bytes that conveys the resource's content.
Whatever result you get from fetching or dereferencing a resource can be said to be its current representational state. The simplest kind of information resource is a file, with one identifier and one representation. A file is functionally inert: its representational state stays put until some procedure comes along and overwrites or deletes it.
The business of Web development ultimately reduces to making collections of resources that do more than files do, though the extent to which this is consciously acknowledged is unclear. I argue, after Fielding and others, that the resource should be the focal point of Web development; that we should always be talking about our work in terms of information resources and the manipulation of their representational states. This is a fiction, to be sure, but it is an incredibly useful one.
Atoms and Molecules
It is much more common for development to be focused on the page or section, rather than the resource. Pages, in practice, are almost always composite: they contain substructures which, if not first-class resources, could be conceived that way. Pages, then, are like molecules, yoking together elementary resources in a particular configuration. Often these substructures are defined as reusable components, but these tend to be fragmentary, and/or not directly addressable, and/or not meant to stand on their own. If we designed these components to be intact, atomic
resources, then we can have settle on one interface for page composition: URLs and HTTP.
Other Helpful Dichotomies
Opaque vs. Transparent Resources
The first dichotomy concerns the way the system treats a resource, the extent to which the system can see into
it.
A resource is opaque if it presents to the system primarily as a blob of data. An opaque resource can be said to have a single authoritative representation, and you can't guarantee other representations will be equivalent.
A transparent resource, by contrast, doesn't have an authoritative representation other than what is internal to a database or live memory. The system can see
the entire resource, and can—and does—address every individual part of it. As such, there is no authoritative string of bytes that represents a transparent resource, because all such representations have to be generated.
Sampled vs. Computed Resources
The second dichotomy concerns where the resource came from.
A resource is sampled if a representation of it entered the system as-is. If you delete a sampled resource you have to go back to wherever you got it from and get it again, which you may not be able to do.
A resource is computed if it is generated by some process under management by the system. If you delete a computed resource, you should be able to recompute it, provided you still have all its inputs—including the process that computed it in the first place.