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

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

Expand Messages
  • 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 1 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 2 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.