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

Re: [rest-discuss] Why do I care about visibility?

Expand Messages
  • Mark Baker
    ... What it said was pretty good though, even just this sentence; Visibility in this case refers to the ability of a component to monitor or mediate the
    Message 1 of 10 , May 1, 2003
    • 0 Attachment
      On Wed, Apr 30, 2003 at 08:42:36PM -0400, Chuck Hinson wrote:
      > So, over the last year or so, I've worked my way through the various
      > concepts of REST - resources, representations, hypermedia as the engine
      > of application state, etc. And now I've come to visibility.
      >
      > I've been trying to get my mind around exactly what visibility means and
      > why its important to REST. I think I have a vague sense of what it is,
      > but I'm not sure I understand why its important. I took a look at
      > Fielding's thesis, but I didn't see much at all on visibility.

      What it said was pretty good though, even just this sentence;

      "Visibility in this case refers to the ability of a component to monitor
      or mediate the interaction between two other components. "

      I think that says it all. Was there something in particular about that
      definition that you had trouble with?

      > Can someone give me an example of why and how visibility is important
      > (in REST). I suspect that one of the examples will involve proxies, so
      > if someone could give an additional example that'd be even better.

      Given the definition, providing an example that doesn't use an
      intermediary would be tough. 8-)

      MB
      --
      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
      Web architecture consulting, technical reports, evaluation & analysis
    • Chuck Hinson
      ... Well, its one of those definitions where my reaction is OK - now what does that mean. I m sure its an accurate and succinct definition, its just too
      Message 2 of 10 , May 1, 2003
      • 0 Attachment
        Mark Baker wrote:

        >On Wed, Apr 30, 2003 at 08:42:36PM -0400, Chuck Hinson wrote:
        >
        >
        >>So, over the last year or so, I've worked my way through the various
        >>concepts of REST - resources, representations, hypermedia as the engine
        >>of application state, etc. And now I've come to visibility.
        >>
        >>I've been trying to get my mind around exactly what visibility means and
        >>why its important to REST. I think I have a vague sense of what it is,
        >>but I'm not sure I understand why its important. I took a look at
        >>Fielding's thesis, but I didn't see much at all on visibility.
        >>
        >>
        >
        >What it said was pretty good though, even just this sentence;
        >
        >"Visibility in this case refers to the ability of a component to monitor
        >or mediate the interaction between two other components. "
        >
        >I think that says it all. Was there something in particular about that
        >definition that you had trouble with?
        >
        >
        Well, its one of those definitions where my reaction is "OK - now what
        does that mean." I'm sure its an accurate and succinct definition, its
        just too terse for my small brain. What are the pros and cons of
        having/not having visibility? How do I determine what or how much an
        intermediary needs to see in order to have 'good' visibility? When is
        something not visible? What does it take to make something visible?

        >>Can someone give me an example of why and how visibility is important
        >>(in REST). I suspect that one of the examples will involve proxies, so
        >>if someone could give an additional example that'd be even better.
        >>
        >>
        >
        >Given the definition, providing an example that doesn't use an
        >intermediary would be tough. 8-).
        >
        OK. I guess I was hoping someone had an example of an intermediary that
        wasn't a proxy or a gateway..

        --Chuck
      • Roy T. Fielding
        ... Why it s important? Hmm... There are several places where it comes into play: o efficient intermediaries - security across trust boundaries Many networks
        Message 3 of 10 , May 1, 2003
        • 0 Attachment
          >> I've been trying to get my mind around exactly what visibility means
          >> and
          >> why its important to REST. I think I have a vague sense of what it
          >> is,
          >> but I'm not sure I understand why its important. I took a look at
          >> Fielding's thesis, but I didn't see much at all on visibility.
          >
          > What it said was pretty good though, even just this sentence;
          >
          > "Visibility in this case refers to the ability of a component to
          > monitor
          > or mediate the interaction between two other components. "

          Why it's important? Hmm...

          There are several places where it comes into play:

          o efficient intermediaries

          - security across trust boundaries

          Many networks don't trust each other, or at least don't trust what
          is on the other side of a firewall. As a result, intermediaries are
          installed to filter traffic. That is a hard problem for
          general-purpose
          application protocols, so we need to make it easier in order to make
          filtering more efficient and gain the trust of firewall admins.

          - extensibility

          Visibility calls for more explicit descriptions within messages, as
          opposed to relying on external IDLs or XDR-style typing by schema,
          which in turn makes it easier to extend the functionality later.

          - evolvability

          When intermediaries can understand a request, they can more easily
          perform or adjust it on behalf of the intended recipient, just as
          WebTV or cell phone networks can adjust for their clients.

          - performance

          Visibility is necessary for cacheability.

          o understandability

          It is simply easier to build complex systems if you can see and
          understand the individual interactions.

          o reusability

          People learn by emulation. That is described somewhat in the
          section
          on Java versus Javascript.

          There are probably others.


          Cheers,

          Roy T. Fielding, Chief Scientist, Day Software
          2 Corporate Plaza, Suite 150
          Newport Beach, CA 92660-7929 fax:+1.949.644.5064
          (roy.fielding@...) <http://www.day.com/>

          Co-founder, The Apache Software Foundation
          (fielding@...) <http://www.apache.org/>
        • Tyler Close
          ... I am wondering how much thought you have put into application security and how it fits in with REST. Do you have a model for how application security
          Message 4 of 10 , May 1, 2003
          • 0 Attachment
            On Thursday 01 May 2003 16:03, Roy T. Fielding wrote:
            > - security across trust boundaries
            >
            > Many networks don't trust each other, or at least don't trust what
            > is on the other side of a firewall. As a result, intermediaries are
            > installed to filter traffic. That is a hard problem for
            > general-purpose
            > application protocols, so we need to make it easier in order to make
            > filtering more efficient and gain the trust of firewall admins.

            I am wondering how much thought you have put into application
            security and how it fits in with REST. Do you have a model for how
            application security should be done? Has there been an exploration
            of how application security affects other REST guidelines? It
            seems like supporting access control has ramifications for many
            parts of REST, the most well-known effect being the interplay of
            HTTP Auth and caching. It seems that if not done carefully,
            access control could negate many of the benefits of REST. What are
            your thoughts?

            Thank you for sharing your expertise.

            Tyler
          • Chuck Hinson
            ... [. . .] So is it fair to say that visibility is about a third party s ability to understand the intent or meaning of a message or an interaction? And
            Message 5 of 10 , May 1, 2003
            • 0 Attachment
              Roy T. Fielding wrote:

              >>>I've been trying to get my mind around exactly what visibility means
              >>>and
              >>>why its important to REST. I think I have a vague sense of what it
              >>>is,
              >>>but I'm not sure I understand why its important. I took a look at
              >>>Fielding's thesis, but I didn't see much at all on visibility.
              >>>
              >>>
              >>What it said was pretty good though, even just this sentence;
              >>
              >>"Visibility in this case refers to the ability of a component to
              >>monitor
              >>or mediate the interaction between two other components. "
              >>
              >>
              >
              >Why it's important? Hmm...
              >
              >There are several places where it comes into play:
              >
              >
              [. . .]

              So is it fair to say that visibility is about a third party's ability to
              understand the intent or meaning of a message or an interaction? And
              increasing visibility is about making it as easy as possible for a third
              party to figure out the intent/meaining of a message?

              Also, does visibility imply the ability of any arbitrary third party to
              understand a message, or does it just mean the ability for some
              particular third party to be able to understand the message. In other
              words, is visibility, to a ceratin extent, application specific (and by
              application I dont mean HTTP, I mean my particular web app built on top
              of HTTP)?

              --Chuck
            • Mark Baker
              I ll take a crack at this if Roy isn t going to, because there s a good question that s really about software architecture in general that I ve given a fair
              Message 6 of 10 , May 5, 2003
              • 0 Attachment
                I'll take a crack at this if Roy isn't going to, because there's a good
                question that's really about software architecture in general that I've
                given a fair amount of thought to.

                On Fri, May 02, 2003 at 12:14:54AM -0400, Chuck Hinson wrote:
                > So is it fair to say that visibility is about a third party's ability to
                > understand the intent or meaning of a message or an interaction?

                Yes.

                > And
                > increasing visibility is about making it as easy as possible for a third
                > party to figure out the intent/meaining of a message?

                Yes.

                > Also, does visibility imply the ability of any arbitrary third party to
                > understand a message, or does it just mean the ability for some
                > particular third party to be able to understand the message.

                Visibility is just the property, and an architectural style has a
                certain amount of it. I would say that any RESTful interaction has at
                least some (large) amount of visibility. "At least", because for any
                given use of it in a "RESTful app", one can probably find additional
                constraints (even unintended ones) that induce additional properties,
                some of which may yield improved visibility. For example, an HTML
                knowledgeable HTTP intermediary has greater visibility into an
                interaction between two components exchanging HTML with HTTP, than it
                does with those same components exchanging SVG.

                What's really going on here, IMO, is that the app I described can be
                viewed as its own system, while remaining a subsystem of the Web. So if
                you created an architectural style which described this subsystem, you
                would likely include all of REST's constraints, but have an additional
                constraint called "Common data format and language", or some such. This
                constraint is what induces the additional visibility in this app beyond
                what REST, by itself, provides.

                But visibility isn't special, of course. Any architectural property
                works the same way.

                MB
                --
                Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                Web architecture consulting, technical reports, evaluation & analysis
              • Roy T. Fielding
                I am swamped trying to finish the URI revision... I ll just add that one thing we want out of an architecture is the ability to adapt to, or be adapted by,
                Message 7 of 10 , May 5, 2003
                • 0 Attachment
                  I am swamped trying to finish the URI revision...

                  I'll just add that one thing we want out of an architecture is the
                  ability to adapt to, or be adapted by, future changes in the evolving
                  way that the system is being used. Life is change.

                  In general, it is far easier to adapt a system that is self-descriptive
                  (high visibility of syntactic and semantic meaning within the structure
                  of communication), both because the interactions are easier for third
                  parties to understand and because the communicating parties are less
                  likely to base their communication on shared out-of-band assumptions:
                  assumptions that may not be applicable in the future. In other words,
                  the components of a successful computing systems are never just
                  communicating among themselves, because success will lead to change
                  and change will lead to new components.

                  ....Roy
                • Roy T. Fielding
                  ... Bunches. ... Even if it is done carefully, access control does negate some goals of REST (shared caching in particular). However, it doesn t negate the
                  Message 8 of 10 , May 5, 2003
                  • 0 Attachment
                    > I am wondering how much thought you have put into application
                    > security and how it fits in with REST.

                    Bunches.

                    > Do you have a model for how
                    > application security should be done? Has there been an exploration
                    > of how application security affects other REST guidelines? It
                    > seems like supporting access control has ramifications for many
                    > parts of REST, the most well-known effect being the interplay of
                    > HTTP Auth and caching. It seems that if not done carefully,
                    > access control could negate many of the benefits of REST. What are
                    > your thoughts?

                    Even if it is done carefully, access control does negate some goals
                    of REST (shared caching in particular). However, it doesn't negate
                    the benefits of the model: a given security model can be analyzed
                    to see how it affects applications that are attempting to communicate
                    using the REST model, and then improved based on those observations.
                    Likewise, security models can learn from the lessons of REST in order
                    to improve their efficiency.

                    I think it is very important to note that the REST model is not ideal
                    for all applications, and that various aspects of security (access
                    control, authentication, authorization, accounting, and privacy of
                    communication) will place requirements on the architecture that need
                    to be addressed in the interaction model.

                    Most sites address this issue by separating secure services from the
                    services that need higher scalability. This is hampered somewhat by
                    the goofy way that WWW browsers warn about "secure" sites containing
                    "insecure" embedded content. Likewise, just about every variation on
                    securing web sites is damaged in one way or another by browser
                    behavior, which is why sites currently use cookies as authenticators.

                    I should note that the big conflict between REST and security models
                    is the fact that REST does not allow for sessions. What needs to be
                    understood is that sessions are bad for security models too -- they
                    cause most of the denial-of-service and man-in-the-middle attacks
                    to be possible. What is needed is an efficient, session-free means
                    of authenticating that is more secure than username/password, which
                    is actually an easy problem to solve if you don't try to solve all
                    of the security problems at once. What is blocking that is the need
                    to negotiate security mechanisms before engaging in secure
                    communication, which is currently done within a session.

                    ....Roy
                  Your message has been successfully submitted and would be delivered to recipients shortly.