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

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

Expand Messages
  • Mike Dierken
    ... From: Chuck Hinson ... Hmm. Good question. For me, visibility also implies standardization, which lets me program a server regardless
    Message 1 of 10 , Apr 30, 2003
    • 0 Attachment
      ----- Original Message -----
      From: "Chuck Hinson" <cmhinson@...>


      > 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.
      >
      > 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.
      >
      Hmm. Good question. For me, visibility also implies standardization, which
      lets me program a server regardless of client - everybody uses the same auth
      header & syntax & meaning. It's not just for intermediaries.
      Visibility for me is also the standardization of key aspects & generic
      aspects of a message - resource identifier, method, authentication,
      representation metadata (content-type...), etc. I'm not all that interested
      in visibility for something like the phone number of someone purchasing a
      book.
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.