rest/opacity
(Adapted from a post by RESTfather Roy Fielding on rest-discuss; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)
Roy on Opacity in REST
Historical Context
...In order to understand TimBL's design notes, you have to know about the context in which he is writing a response. In this case, various thoughts were recorded as the "Opacity Axiom" in response to a discussion about client behavior and the perceived need for URNs. It has long since been taken out of context and abused in various ways.
Also, keep in mind that TimBL's design note was written two years after Henrik and I [Roy Fielding] worked out the important bits of what would become the HTTP object model, later re-named REST to get away from OOM terms, about 18 months after we had similar discussions at MIT with TimBL and the rest of the W3C team, and more than a year after HTTP/1.0 was finished and HTTP/1.1 proposed. So, saying it was something that I "didn't really care to integrate so much" is missing the mark by quite a bit -- he is trying to describe our model to people who did not understand it.
Original Intent
The opacity principle, as actually used on the Web, refers only to the machine interpretation of request processing as being dependent on control data (e.g., hypertext anchors and message field names) rather than on metadata appearing within the URI. It is the same reason why we distinguish media types from data formats -- the fact that a string of bytes looks like angle tags doesn't mean we want to process it as HTML. Ignoring any semantically significant data in a URI allows operations on a resource to be orthogonal to identification of the resource.
REST does include the opacity axiom in the original sense of that phrase. I did not use it by name in REST because it isn't a principle at all -- opacity is just a name TimBL used for the set of constraints around URI processing by clients (a byproduct of the constraints that you will find in REST). The principle involved is orthogonal design.
Applicability to Clients
"Opacity of URI" only applies to clients and, even then, only to those parts of the URI that are not defined by relevant standards. Origin servers, for example, have the choice of interpreting a URI as being opaque or as a structure that defines how the server maps the URI to a representation of the resource. Cool URIs will often make a transition from being originally interpreted as structure by the server and then later treated as an opaque string (perhaps because the server implementation has changed and the owner wants the old URI to persist). The server can make that transition because clients are required to act like they are ignorant of the server-private structure.
Clients are allowed to treat a URI as being structured if that structure is defined by standard (e.g., scheme and authority in "http") or if the server tells the client how its URI is structured. For example, both GET-based FORM actions and server-side image map processing compose the URI from a server-provided base and a user-supplied suffix constructed according to an algorithm defined by a standard media type.
The Bottom Line
Note, however, that some people have taken the mere title of "opacity" and assumed that it meant URIs should not have meaningful construction at all. TimBL's axiom doesn't say that and neither does REST.
Summary by Jon Hanna
Opacity Option
I think it's important that URIs *can* be treated opaquely - you can link to them, you can cache their resources without processing them beyond naive string-matching, process RDF graphs again without processing them beyond naive string-matching, and so on.
Non-Opacity Option
This does not preclude the fact that agents *may* construct or parse URIs in more sophisticated ways, it just means that agents don't have to, especially in the case of agents that are not aware of the specific purpose of the application.