Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] opaque URIs and RFC 2397 URIs

Expand Messages
  • Jon Hanna
    ... Opaqueness means that *in general* a URI can be treated as if none of its parts are semantically significant. Now, a process may treat a URI s parts as
    Message 1 of 11 , Nov 1, 2005
    • 0 Attachment
      Dr. Ernie Prabhakar wrote:
      > Hi Jon (and hello again Lucas :-),
      >
      > I wonder if I'm missing the whole point about "opaqueness." What
      > exactly does that mean? s." What problem is that intended to solve?

      Opaqueness means that *in general* a URI can be treated as if none of
      its parts are semantically significant.

      Now, a process may treat a URI's parts as being significant in a few
      ways - when dereferencing it it is necessary to extract the host to find
      the server to connect to, the server can treat the rest as significant
      in some way, or can map it to a file system which in turn will treat it
      as significant and the client can treat it as significant in
      constructing it, but generally will not (merely using a URI it has found
      in a hypertext document when it dereferenced a previous URI).

      Hence, for example, a caching proxy need know nothing about the
      significance of a URI, it uses it only as a string to identify the
      collection of headers and data that it stores and passes on (as
      instructed by said headers). A browser need not know if a URI in a <img
      /> element refers to a file or a process which dynamically generates an
      image, and an RDF parser need know nothing about the URI beyond the
      string of characters that composes it.

      HTTP URIs are not entirely opaque in this fashion, since for historical
      reasons the presence or absense of a query portion dictates the default
      caching behaviour in the case of their being no relevant headers.
    • Roy T. Fielding
      ... No, it is just that people are different from machines, servers are different from clients, and TimBL used the word Axiom to mean architectural
      Message 2 of 11 , Nov 1, 2005
      • 0 Attachment
        On Oct 31, 2005, at 9:06 PM, Seth Johnson wrote:
        > I thought Josh's explanation made sense. Analyzing the URL moves
        > away from treating hypermedia as the engine of application
        > state. That said, it appears that opacity isn't so much a
        > principle of REST as it's an original principle of the web that
        > Fielding didn't really care to integrate so much.

        No, it is just that people are different from machines,
        servers are different from clients, and TimBL used the word
        "Axiom" to mean architectural constraint. 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 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.

        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.

        "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.

        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.

        Cheers,

        Roy T. Fielding <http://roy.gbiv.com/>
        Chief Scientist, Day Software <http://www.day.com/>
      • Seth Johnson
        Hello Roy, Thanks for this clarification! Seth ... -- RIAA is the RISK! Our NET is P2P! http://www.nyfairuse.org/action/ftc DRM is Theft! We are the
        Message 3 of 11 , Nov 1, 2005
        • 0 Attachment
          Hello Roy,

          Thanks for this clarification!


          Seth


          "Roy T. Fielding" wrote:
          >
          > On Oct 31, 2005, at 9:06 PM, Seth Johnson wrote:
          > > I thought Josh's explanation made sense. Analyzing the URL moves
          > > away from treating hypermedia as the engine of application
          > > state. That said, it appears that opacity isn't so much a
          > > principle of REST as it's an original principle of the web that
          > > Fielding didn't really care to integrate so much.
          >
          > No, it is just that people are different from machines,
          > servers are different from clients, and TimBL used the word
          > "Axiom" to mean architectural constraint. 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 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.
          >
          > 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.
          >
          > "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.
          >
          > 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.
          >
          > Cheers,
          >
          > Roy T. Fielding <http://roy.gbiv.com/>
          > Chief Scientist, Day Software <http://www.day.com/>
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >

          --

          RIAA is the RISK! Our NET is P2P!
          http://www.nyfairuse.org/action/ftc

          DRM is Theft! We are the Stakeholders!

          New Yorkers for Fair Use
          http://www.nyfairuse.org

          [CC] Counter-copyright: http://realmeasures.dyndns.org/cc

          I reserve no rights restricting copying, modification or
          distribution of this incidentally recorded communication.
          Original authorship should be attributed reasonably, but only so
          far as such an expectation might hold for usual practice in
          ordinary social discourse to which one holds no claim of
          exclusive rights.
        Your message has been successfully submitted and would be delivered to recipients shortly.