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

Request Header vs. Query String

Expand Messages
  • Sandeep Shetty
    Hey, There are a lot of places on the web where I have seen people specify client preferences (acceptable media types, languages, etc.) in the Query String
    Message 1 of 23 , Apr 6, 2006
    • 0 Attachment
      Hey,

      There are a lot of places on the web where I have seen people specify
      client preferences (acceptable media types, languages, etc.) in the
      Query String which has got me thinking about why this is
      inappropriate. The obvious reason for why they do this is that there
      is limited support for tweaking request headers in Browserland [3] and
      all too easy (testing via browser, etc.) to add stuff to the most
      easily editable data element - the URL. Another reason why they might
      do this is if they consider the different data formats as separate
      resources.

      My understanding is that Request Headers are used for parametrising
      the request [1] and the Query String is used for parametrising the
      resource [2]. If this is the case then you cannot put information in
      the Query String that belongs in the Request Header because the Query
      String in some sense affects the identity of the resource but the
      Request Headers don't (this is true if like me you believe that the
      different formats are not separate resources).

      Is this correct or am I way off?

      Sandeep Shetty
      http://sandeep.shetty.in/


      [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3
      [2] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#query
      [3] http://sandeep.shetty.in/2006/04/browserland-http.html
    • Joe Gregorio
      ... Query parameters are a convenient way to construct URIs for resources, for example, GET-based HTML forms. Look at these two URIs:
      Message 2 of 23 , Apr 6, 2006
      • 0 Attachment
        On 4/6/06, Sandeep Shetty <sandeep.shetty@...> wrote:
        > Hey,
        >
        > There are a lot of places on the web where I have seen people specify
        > client preferences (acceptable media types, languages, etc.) in the
        > Query String which has got me thinking about why this is
        > inappropriate. The obvious reason for why they do this is that there
        > is limited support for tweaking request headers in Browserland [3] and
        > all too easy (testing via browser, etc.) to add stuff to the most
        > easily editable data element - the URL. Another reason why they might
        > do this is if they consider the different data formats as separate
        > resources.
        >
        > My understanding is that Request Headers are used for parametrising
        > the request [1] and the Query String is used for parametrising the
        > resource [2].

        Query parameters are a convenient way to construct URIs for
        resources, for example, GET-based HTML forms. Look at these
        two URIs:

        http://www.google.com/search?q=REST
        http://www.google.com/search?q=This+is+spinal+tap

        I don't think you'd consider google.com one big resource.

        I don't think trying to squeeze all request headers
        under the label of "parametrising the request"
        is really correct (think of Cache-Control:
        and Connection:). There *are* request headers, such as Accept:,
        but I wouldn't refer to them
        as "parametrising the request" as much as
        "parametrising the respresentation".

        > If this is the case then you cannot put information in
        > the Query String that belongs in the Request Header because the Query
        > String in some sense affects the identity of the resource but the
        > Request Headers don't (this is true if like me you believe that the
        > different formats are not separate resources).

        If you do have a resource that does some form
        of content negotiation, which is what we're talking
        about here, it is still useful to have URIs for
        particular representations:

        http://bitworking.org/news/WebServicesAndContentNegotiation

        -joe

        --
        Joe Gregorio http://bitworking.org
      • Sandeep Shetty
        Hey Joe, ... google.com is the naming authority and /search is the resource. You don t have to think of /search as one big resource that contains these small
        Message 3 of 23 , Apr 7, 2006
        • 0 Attachment
          Hey Joe,

          On 4/7/06, Joe Gregorio <joe.gregorio@...> wrote:
          > On 4/6/06, Sandeep Shetty <sandeep.shetty@...> wrote:
          > > My understanding is that Request Headers are used for parametrising
          > > the request [1] and the Query String is used for parametrising the
          > > resource [2].
          >
          > Query parameters are a convenient way to construct URIs for
          > resources, for example, GET-based HTML forms. Look at these
          > two URIs:
          >
          > http://www.google.com/search?q=REST
          > http://www.google.com/search?q=This+is+spinal+tap
          >
          > I don't think you'd consider google.com one big resource.

          google.com is the naming authority and /search is the resource. You
          don't have to think of /search as one big resource that contains these
          small resources specified via a Query String. You can think of it as a
          resource that gives you some way of getting to other resources by
          providing "identifying information" [1] in the Query String.

          Note that both the URI's (including the query mark and the query
          string after it) you mentioned *are used to identify* quasi-static [2]
          resources which can be cached till the next time google updates its
          index.


          > I don't think trying to squeeze all request headers
          > under the label of "parametrising the request"
          > is really correct (think of Cache-Control:
          > and Connection:). There *are* request headers, such as Accept:,
          > but I wouldn't refer to them
          > as "parametrising the request" as much as
          > "parametrising the respresentation".

          I'm not giving it that label, the spec is:
          "These (request-header) fields act as request modifiers," [3]

          According to the spec [4]:
          "Accept headers can be used to indicate that the *request is
          specifically limited* to a small set of desired types, as in the case
          of a request for an in-line image."

          So the Accept header *is* a request modifier.

          Also, Cache-Control [5] and Connection [6] are both general-header
          fields and not request-header fields.


          > > If this is the case then you cannot put information in
          > > the Query String that belongs in the Request Header because the Query
          > > String in some sense affects the identity of the resource but the
          > > Request Headers don't (this is true if like me you believe that the
          > > different formats are not separate resources).
          >
          > If you do have a resource that does some form
          > of content negotiation, which is what we're talking
          > about here, it is still useful to have URIs for
          > particular representations:


          I agree but only in the case of reactive (agent-driven) negotiation [7].


          Sandeep Shetty
          http://sandeep.shetty.in/


          [1] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#query
          [2] http://www.w3.org/DesignIssues/Axioms.html#Query
          [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3
          [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
          [5] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
          [6] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10
          [7] http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3_2_7
        • Bill Venners
          Hi Sandeep, ... I think there s some overloading of the term resource going on here. The way I ve come to think of it, a resource is that which is identified
          Message 4 of 23 , Apr 7, 2006
          • 0 Attachment
            Hi Sandeep,

            On Apr 7, 2006, at 1:21 AM, Sandeep Shetty wrote:

            > Hey Joe,
            >
            > On 4/7/06, Joe Gregorio <joe.gregorio@...> wrote:
            >> On 4/6/06, Sandeep Shetty <sandeep.shetty@...> wrote:
            >>> My understanding is that Request Headers are used for parametrising
            >>> the request [1] and the Query String is used for parametrising the
            >>> resource [2].
            >>
            >> Query parameters are a convenient way to construct URIs for
            >> resources, for example, GET-based HTML forms. Look at these
            >> two URIs:
            >>
            >> http://www.google.com/search?q=REST
            >> http://www.google.com/search?q=This+is+spinal+tap
            >>
            >> I don't think you'd consider google.com one big resource.
            >
            > google.com is the naming authority and /search is the resource. You
            > don't have to think of /search as one big resource that contains these
            > small resources specified via a Query String. You can think of it as a
            > resource that gives you some way of getting to other resources by
            > providing "identifying information" [1] in the Query String.
            >
            > Note that both the URI's (including the query mark and the query
            > string after it) you mentioned *are used to identify* quasi-static [2]
            > resources which can be cached till the next time google updates its
            > index.
            >
            I think there's some overloading of the term resource going on here.
            The way I've come to think of it, a resource is that which is
            identified by a URI. So if it's a different URI, it is a different
            resource. Therefore, the following are two different resources:

            http://www.google.com/search?q=REST
            http://www.google.com/search?q=This+is+spinal+tap

            My definition of resource comes from the HTTP perspective. You said,
            "You don't have to think of /search as being on big resource..." To
            me, you're not talking about the HTTP perspective here, but about how
            humans would think of the information architecture of Google. I think
            that's important to consider when designing a web app, because the
            URI is part of the user interface. URIs can be designed to help the
            user understand and better navigate the site. But users don't think
            in terms of resources. For lack of a better word, I'll use "content."

            As an illustration, I posted a question to this list recently about
            whether it made sense to consider personalization of a resource a
            representation of that resource. I eventually realized that the
            trouble with that approach is that if you have 1000 ETags for 1000
            different personalized versions of a resource, and a proxy has all of
            them cached, the If-None-Match request header would likely be bigger
            than size of the representation. That defeats the purpose of caching,
            which tells me that the number of possible representations, and
            therefore ETags, for each resource needs to be fairly small.

            So now, if you search Google for REST and hit this page on one of my
            sites:

            http://lejava.artima.com/articles/rest_easy

            I'll notice that the referrer was:

            http://www.google.com/search?q=REST

            And I'll redirect the browser to:

            http://lejava.artima.com/articles/rest_easy?q=REST

            This URI will show the same article, but with the term "rest"
            highlighted. From the HTTP perspective, these are two different
            resources:

            http://lejava.artima.com/articles/rest_easy
            http://lejava.artima.com/articles/rest_easy?q=REST

            But from the user's perspective, they are two different views of the
            same piece of content, which is an article about REST. Therefore, the
            query string parameterizes the content, from the user's perspective,
            but not the resource. From the HTTP perspective, a URI is opaque, and
            each unique string identifies a unique resource regardless of whether
            it contains a question mark.

            Does this way of thinking about the term "resource" sound correct?

            Bill
            ----
            Bill Venners
            Editor-in-Chief
            Artima Developer
            http://www.artima.com
          • Jon Hanna
            ... Pretty much, though I d say that http://lejava.artima.com/articles/rest_easy and http://lejava.artima.com/articles/rest_easy?q=REST *could* refer to
            Message 5 of 23 , Apr 7, 2006
            • 0 Attachment
              Bill Venners wrote:
              > Does this way of thinking about the term "resource" sound correct?

              Pretty much, though I'd say that
              http://lejava.artima.com/articles/rest_easy and
              http://lejava.artima.com/articles/rest_easy?q=REST *could* refer to
              different resources. They could also be the same resource, just as two
              names could identify the same person, two C++ pointers could point to
              the same object, etc.

              For the most part we should of course assume that the two are different
              resources (the aliasing will remain hidden from us).
            • Sandeep Shetty
              Hey Bill, ... This is what I m saying as well. ... Oh! I wasn t going down that road. I was just trying to explain to Joe (who said I don t think you d
              Message 6 of 23 , Apr 7, 2006
              • 0 Attachment
                Hey Bill,

                On 4/7/06, Bill Venners <bv-svp@...> wrote:
                > I think there's some overloading of the term resource going on here.
                > The way I've come to think of it, a resource is that which is
                > identified by a URI. So if it's a different URI, it is a different
                > resource. Therefore, the following are two different resources:
                >
                > http://www.google.com/search?q=REST
                > http://www.google.com/search?q=This+is+spinal+tap

                This is what I'm saying as well.


                > My definition of resource comes from the HTTP perspective. You said,
                > "You don't have to think of /search as being on big resource..." To
                > me, you're not talking about the HTTP perspective here, but about how
                > humans would think of the information architecture of Google. I think
                > that's important to consider when designing a web app, because the
                > URI is part of the user interface. URIs can be designed to help the
                > user understand and better navigate the site. But users don't think
                > in terms of resources. For lack of a better word, I'll use "content."

                Oh! I wasn't going down that road. I was just trying to explain to Joe
                (who said "I don't think you'd consider google.com one big resource."
                by which he meant something like "When you say that the Query String
                is used for parametrising the resource, do you think the Query String
                in http://www.google.com/search?q=REST or
                http://www.google.com/search?q=This+is+spinal+tap is parametrising
                google.com"?) that parametising the resource in a sense meant creating
                identifiers to new resources (which could be sub-resources or
                orthogonal resources).


                > So now, if you search Google for REST and hit this page on one of my
                > sites:
                >
                > http://lejava.artima.com/articles/rest_easy
                >
                > I'll notice that the referrer was:
                >
                > http://www.google.com/search?q=REST
                >
                > And I'll redirect the browser to:
                >
                > http://lejava.artima.com/articles/rest_easy?q=REST
                >
                > This URI will show the same article, but with the term "rest"
                > highlighted.

                This is not how I would do this. You could do this in a cache friendly
                way on the client side (with javascript using document.referrer) and
                not create a new resource just for highlighting search terms.


                > From the HTTP perspective, these are two different
                > resources:
                >
                > http://lejava.artima.com/articles/rest_easy
                > http://lejava.artima.com/articles/rest_easy?q=REST
                >
                > But from the user's perspective, they are two different views of the
                > same piece of content, which is an article about REST. Therefore, the
                > query string parameterizes the content, from the user's perspective,
                > but not the resource. From the HTTP perspective, a URI is opaque, and
                > each unique string identifies a unique resource regardless of whether
                > it contains a question mark.

                The Query String is parametrising the content from the user's
                perspective and not the resource because *you* designed it that way.
                You could do it in the way I mentioned above and that would not be the
                case.

                Let me re-state what I meant in my first post [1]:
                Request modifiers should not be put in the Query String because
                request modifiers are not supposed to affect the identify of a
                resource. When you put request modifiers in the Query String you are
                creating new resources where you shouldn't.


                Sandeep Shetty
                http://sandeep.shetty.in/


                [1] http://groups.yahoo.com/group/rest-discuss/message/5844
              • Sandeep Shetty
                ... Case in point: http://developer.yahoo.com/common/phpserial.html#outputparam Sandeep Shetty http://sandeep.shetty.in/
                Message 7 of 23 , Apr 7, 2006
                • 0 Attachment
                  On 4/7/06, Sandeep Shetty <sandeep.shetty@...> wrote:
                  > Let me re-state what I meant in my first post [1]:
                  > Request modifiers should not be put in the Query String because
                  > request modifiers are not supposed to affect the identify of a
                  > resource. When you put request modifiers in the Query String you are
                  > creating new resources where you shouldn't.

                  Case in point: http://developer.yahoo.com/common/phpserial.html#outputparam


                  Sandeep Shetty
                  http://sandeep.shetty.in/
                • Bill Venners
                  Hi Sandeep, ... Yes, you re right. I have a fear of JavaScript that I need to get over. My concern is the test matrix. I like the fact that I can check what
                  Message 8 of 23 , Apr 7, 2006
                  • 0 Attachment
                    Hi Sandeep,

                    > This is not how I would do this. You could do this in a cache friendly
                    > way on the client side (with javascript using document.referrer) and
                    > not create a new resource just for highlighting search terms.
                    >
                    Yes, you're right. I have a fear of JavaScript that I need to get
                    over. My concern is the test matrix. I like the fact that I can check
                    what comes out of:

                    http://lejava.artima.com/articles/rest_easy?q=REST

                    And know that the XHTML is correct when it leaves the server. But
                    truth is I plan to do JavaScript stuff anyway, so I need to figure
                    out a way to test what the XHTML looks like after the JavaScript
                    runs. Then I may as well do the keyword highlighting that way.

                    >>
                    >> http://lejava.artima.com/articles/rest_easy
                    >> http://lejava.artima.com/articles/rest_easy?q=REST
                    >>
                    >> But from the user's perspective, they are two different views of the
                    >> same piece of content, which is an article about REST. Therefore, the
                    >> query string parameterizes the content, from the user's perspective,
                    >> but not the resource. From the HTTP perspective, a URI is opaque, and
                    >> each unique string identifies a unique resource regardless of whether
                    >> it contains a question mark.
                    >
                    > The Query String is parametrising the content from the user's
                    > perspective and not the resource because *you* designed it that way.
                    > You could do it in the way I mentioned above and that would not be the
                    > case.
                    >
                    I agree. I am aiming for RESTful and user-friendly URL design for
                    content-oriented sites.

                    > Let me re-state what I meant in my first post [1]:
                    > Request modifiers should not be put in the Query String because
                    > request modifiers are not supposed to affect the identify of a
                    > resource. When you put request modifiers in the Query String you are
                    > creating new resources where you shouldn't.
                    >
                    I think I see. I believe I was thrown I was thrown by the word
                    "creating." Basically, I think you're saying that you shouldn't
                    specify data to be used for content negotiation in query parameters
                    because each set of query parameters embodies a different URI, which
                    implies a different resource. Whereas request headers parameterize
                    the same URI, which implies the same resource. Is that correct?

                    If so, I agree with that, though I am leaning away from most content
                    negotiation anyway. For usability reasons, I think an article
                    translated into different languages should each have a different URI
                    for each language. Likewise for usability I think the PDF form of an
                    article should have a different URI from the HTML form. I do think
                    content negotiation would be OK for things like deciding between GIF
                    and PNF for an image, i.e., for forms of content that are
                    "commodities" or very substitutable.

                    Bill
                    ----
                    Bill Venners
                    Editor-in-Chief
                    Artima Developer
                    http://www.artima.com
                  • Sandeep Shetty
                    Hey Bill, ... More or less, except I m not just talking about content negotiation but about all the request-header fields (conneg, authorization, etc.). Also,
                    Message 9 of 23 , Apr 8, 2006
                    • 0 Attachment
                      Hey Bill,

                      On 4/8/06, Bill Venners <bv-svp@...> wrote:
                      > > Let me re-state what I meant in my first post [1]:
                      > > Request modifiers should not be put in the Query String because
                      > > request modifiers are not supposed to affect the identify of a
                      > > resource. When you put request modifiers in the Query String you are
                      > > creating new resources where you shouldn't.
                      > >
                      > I think I see. I believe I was thrown I was thrown by the word
                      > "creating." Basically, I think you're saying that you shouldn't
                      > specify data to be used for content negotiation in query parameters
                      > because each set of query parameters embodies a different URI, which
                      > implies a different resource. Whereas request headers parameterize
                      > the same URI, which implies the same resource. Is that correct?

                      More or less, except I'm not just talking about content negotiation
                      but about all the request-header fields (conneg, authorization, etc.).
                      Also, request-headers parametrize the request which can be for the
                      same URI. This is about moving away from the "URI as a document
                      identifier" definition and moving towards the "URI represents a
                      resource (conceptual entity)" definition which is more in line with
                      REST [1]. Remember, cool URIs don't change [2].

                      > If so, I agree with that, though I am leaning away from most content
                      > negotiation anyway. For usability reasons, I think an article
                      > translated into different languages should each have a different URI
                      > for each language. Likewise for usability I think the PDF form of an
                      > article should have a different URI from the HTML form. I do think
                      > content negotiation would be OK for things like deciding between GIF
                      > and PNF for an image, i.e., for forms of content that are
                      > "commodities" or very substitutable.

                      I know what you mean especially from an usability perspective given
                      the current state of affairs [3] but there is a cost involved in doing
                      this as you might end up fragmenting your resource space. Say one of
                      the articles on your website was about an "Interview with Mr. Foo Bar"
                      and you had two versions of it, one in English
                      (http://artima.com/articles/en/interview-with-foo-bar.html) and
                      another in French
                      (http://artima.com/articles/fr/interview-with-foo-bar.html). Now
                      suppose this article is viewed a lot by your English speaking audience
                      and they happen to point to it from various places on the web, you end
                      up undervaluing the French version which is actually the same
                      resource. Apart from this, request-headers give us a standard way to
                      parametrize the request and get to the different representations
                      whereas buy putting this information in the URI in a non-standard way
                      makes its harder to get to the other representations.

                      Example:

                      http://artima.com/articles/interview-with-foo-bar
                      Accept: text/html

                      By changing the Accept header to application/pdf like so

                      http://artima.com/articles/interview-with-foo-bar
                      Accept: application/pdf

                      a client can easily get to the other format. Similarly, if the French
                      speaking reader visits the site he is automatically (provided his
                      browser is setup properly) presented the french version of the
                      article. If this was not the case and since the French version was
                      undervalued (due to the lack of links pointing to it), he might have
                      ended up finding the English version through a search engine and then
                      would have to choose (using a non-standard way) the French version.


                      Sandeep Shetty
                      http://sandeep.shetty.in/


                      [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2_1
                      [2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-persistence
                      [3] http://sandeep.shetty.in/2006/04/browserland-http.html
                    • Bill Venners
                      Hi Sandeep, ... What you describe sound to me like the approach envisioned by the HTTP designers when they designed content negotiation, and in Roy Fielding s
                      Message 10 of 23 , Apr 10, 2006
                      • 0 Attachment
                        Hi Sandeep,

                        On Apr 8, 2006, at 8:22 AM, Sandeep Shetty wrote:

                        >> If so, I agree with that, though I am leaning away from most content
                        >> negotiation anyway. For usability reasons, I think an article
                        >> translated into different languages should each have a different URI
                        >> for each language. Likewise for usability I think the PDF form of an
                        >> article should have a different URI from the HTML form. I do think
                        >> content negotiation would be OK for things like deciding between GIF
                        >> and PNF for an image, i.e., for forms of content that are
                        >> "commodities" or very substitutable.
                        >
                        > I know what you mean especially from an usability perspective given
                        > the current state of affairs [3] but there is a cost involved in doing
                        > this as you might end up fragmenting your resource space. Say one of
                        > the articles on your website was about an "Interview with Mr. Foo Bar"
                        > and you had two versions of it, one in English
                        > (http://artima.com/articles/en/interview-with-foo-bar.html) and
                        > another in French
                        > (http://artima.com/articles/fr/interview-with-foo-bar.html). Now
                        > suppose this article is viewed a lot by your English speaking audience
                        > and they happen to point to it from various places on the web, you end
                        > up undervaluing the French version which is actually the same
                        > resource. Apart from this, request-headers give us a standard way to
                        > parametrize the request and get to the different representations
                        > whereas buy putting this information in the URI in a non-standard way
                        > makes its harder to get to the other representations.
                        >
                        > Example:
                        >
                        > http://artima.com/articles/interview-with-foo-bar
                        > Accept: text/html
                        >
                        > By changing the Accept header to application/pdf like so
                        >
                        > http://artima.com/articles/interview-with-foo-bar
                        > Accept: application/pdf
                        >
                        > a client can easily get to the other format. Similarly, if the French
                        > speaking reader visits the site he is automatically (provided his
                        > browser is setup properly) presented the french version of the
                        > article. If this was not the case and since the French version was
                        > undervalued (due to the lack of links pointing to it), he might have
                        > ended up finding the English version through a search engine and then
                        > would have to choose (using a non-standard way) the French version.
                        >
                        > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/
                        > evaluation.htm#sec_6_2_1
                        > [2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-persistence
                        > [3] http://sandeep.shetty.in/2006/04/browserland-http.html
                        >
                        What you describe sound to me like the approach envisioned by the
                        HTTP designers when they designed content negotiation, and in Roy
                        Fielding's dissertation when he discusses REST. I would contest your
                        statement, "a client can easily get to the other format," and suggest
                        that is the main usability problem with content negotiation as
                        envisioned in the HTTP spec and REST.

                        In both examples you give, I believe users want to be able to chose
                        between representations. Most users don't understand request headers,
                        or how to set their preferences. With a bit of looking around, I
                        found how to do it in my main browser, Firefox on the Mac. So being a
                        somewhat sophisticated surfer, I could set my preference for French
                        ahead of English.

                        Now imagine I click on your [1] footnote to see a section of Roy
                        Fielding's dissertation, and being true to itself, it sends back a
                        French translation of that chapter of his dissertation. Well, even
                        though I normally prefer French while surfing, in this case, imagine
                        I'm doing research for a paper of my own I'm writing and I really
                        want the English version, because that's the authoritative version:
                        the version of record. To get it, I would need to go to my browser
                        settings and move English above French, then click reload. Then go
                        back to my preferences to move French back on top, which is what I
                        prefer most of the time. The problem is that most users will have no
                        idea how to solve that problem, and for those sophisticated users who
                        do, it is a pain.

                        What I'm planning to do at Artima is send back the English version,
                        but with a prominent link to the French version. If you really prefer
                        the French version, it is one click away. So I do content negotiation
                        in that when I notice the user prefers French over English, and they
                        have requested an English article for which there is a French
                        translation, I send them a representation of the English article that
                        includes a prominent link to the French translation. This allows the
                        user to indicate his or her preference with a mouse click rather than
                        going in and editing preferences, which is more user-friendly.

                        The situation with HTML and PDF representations of an article, which
                        you also described, is similar. Although je ne parle pas Francais, I
                        do use both PDF and HTML, so I can use myself as an example user. I
                        prefer HTML for on screen reading, but PDF for printing. For longer
                        written works--article length and longer--I prefer to print and read
                        on paper. I have printed Roy Fielding's thesis out, for example. I
                        would have preferred to actually get a PDF version of that thesis for
                        printing, but I didn't see one. Since I prefer HTML most of the time,
                        for me to get the PDF version I suppose I'd have to go change my
                        preferences and put PDF ahead of HTML (except I don't see any way to
                        do that in Firefox.) But that preference change would be just for his
                        thesis, and only if I happen to be interested in printing it. When
                        following one of your footnotes to Roy's dissertation from an email,
                        for example, I actually just prefer the HTML version because I want
                        to read a few paragraphs on screen. Even if I want to read a whole
                        chapter, I only want the PDF if I'm near a printer and have enough
                        ink and paper. So at Artima, my plan is to show the HTML version of
                        an article, and include a link on it to a PDF version.

                        The problem with the envisioned HTTP/RESTful approach to content
                        negotiation is that different human language representations of an
                        article such as French/English, and file format differences such as
                        HTML/PDF, are not information commodities to users. You can't just
                        replace one with the other. It does matter to the user which one you
                        give them, and what they want depends on the situation. The server
                        needs to negotiate with the *user*, not the user agent, to figure out
                        what representation they want in each specific situation. For non-
                        commodities, I believe the best way to do that is to give them a
                        different URI for each, because then the user can express his or her
                        wishes with a click.

                        Some things that I can imagine doing as-envisioned content
                        negotiation on are things that really are information commodities
                        from the perspective of the user, such as PNG and GIF. Either one you
                        send should provide the user with the same experience, and the user
                        probably doesn't care which one the browser uses to construct the
                        image it displays. So here it seems fine to me to do content
                        negotiation as envisioned by HTTP. Note that in this case, what you
                        are really negotiating with is the user agent, not the user.

                        One place I'm not sure which way to go is with a version of a URI fit
                        for small screens, such as Blackberries. I could just adjust the page
                        when I guess from the request that they are on a small screen, or I
                        could include a link to a small screen version. But that would really
                        mean there's two different sets of pages, one for desktop computers
                        and laptops, and one for mobile devices. I haven't figured out what
                        to do in this case, but I think that allowing access from mobile
                        devices will be important, and suspect that just sending the same
                        thing to big and small screens won't make users happy. I welcome
                        suggestions.

                        Bill
                        ----
                        Bill Venners
                        Editor-in-Chief
                        Artima Developer
                        http://www.artima.com
                      • Roy T. Fielding
                        ... Whoa, I think this is a case of reading too much into my dissertation. The sites that I produce *always* separate languages into separate URI trees. Day
                        Message 11 of 23 , Apr 10, 2006
                        • 0 Attachment
                          On Apr 10, 2006, at 12:48 PM, Bill Venners wrote:
                          > On Apr 8, 2006, at 8:22 AM, Sandeep Shetty wrote:
                          >
                          >>> If so, I agree with that, though I am leaning away from most content
                          >>> negotiation anyway. For usability reasons, I think an article
                          >>> translated into different languages should each have a different URI
                          >>> for each language. Likewise for usability I think the PDF form of an
                          >>> article should have a different URI from the HTML form. I do think
                          >>> content negotiation would be OK for things like deciding between GIF
                          >>> and PNF for an image, i.e., for forms of content that are
                          >>> "commodities" or very substitutable.
                          >>
                          >> I know what you mean especially from an usability perspective given
                          >> the current state of affairs [3] but there is a cost involved in
                          >> doing
                          >> this as you might end up fragmenting your resource space. Say one of
                          >> the articles on your website was about an "Interview with Mr. Foo
                          >> Bar"
                          >> and you had two versions of it, one in English
                          >> (http://artima.com/articles/en/interview-with-foo-bar.html) and
                          >> another in French
                          >> (http://artima.com/articles/fr/interview-with-foo-bar.html). Now
                          >> suppose this article is viewed a lot by your English speaking
                          >> audience
                          >> and they happen to point to it from various places on the web, you
                          >> end
                          >> up undervaluing the French version which is actually the same
                          >> resource. Apart from this, request-headers give us a standard way to
                          >> parametrize the request and get to the different representations
                          >> whereas buy putting this information in the URI in a non-standard way
                          >> makes its harder to get to the other representations.
                          >>
                          >> Example:
                          >>
                          >> http://artima.com/articles/interview-with-foo-bar
                          >> Accept: text/html
                          >>
                          >> By changing the Accept header to application/pdf like so
                          >>
                          >> http://artima.com/articles/interview-with-foo-bar
                          >> Accept: application/pdf
                          >>
                          >> a client can easily get to the other format. Similarly, if the French
                          >> speaking reader visits the site he is automatically (provided his
                          >> browser is setup properly) presented the french version of the
                          >> article. If this was not the case and since the French version was
                          >> undervalued (due to the lack of links pointing to it), he might have
                          >> ended up finding the English version through a search engine and then
                          >> would have to choose (using a non-standard way) the French version.
                          >>
                          >> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/
                          >> evaluation.htm#sec_6_2_1
                          >> [2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-persistence
                          >> [3] http://sandeep.shetty.in/2006/04/browserland-http.html
                          >>
                          > What you describe sound to me like the approach envisioned by the
                          > HTTP designers when they designed content negotiation, and in Roy
                          > Fielding's dissertation when he discusses REST. I would contest your
                          > statement, "a client can easily get to the other format," and suggest
                          > that is the main usability problem with content negotiation as
                          > envisioned in the HTTP spec and REST.

                          Whoa, I think this is a case of reading too much into my dissertation.
                          The sites that I produce *always* separate languages into separate
                          URI trees. Day Software's Communiqué product specializes in
                          multilingual
                          sites and defaults to separate trees. E.g., if you follow a link to

                          http://www.day.com/

                          then the site will redirect according to the user's preference to one of

                          http://www.day.com/site/en/index.html
                          http://www.day.com/site/de/index.html

                          and those pages, in turn, link to all three. We are a Swiss company and
                          experts at multilingual sites.

                          In general, I avoid content negotiation without redirects like the
                          plague because of its effect on caching.

                          Now, section 6.2.1 does not say that content negotiation should be
                          used all the time. It says

                          The definition of resource in REST is based on a simple premise:
                          identifiers should change as infrequently as possible. Because
                          the Web uses embedded identifiers rather than link servers, authors
                          need an identifier that closely matches the semantics they intend by
                          a hypermedia reference, allowing the reference to remain static even
                          though the result of accessing that reference may change over time.
                          REST accomplishes this by defining a resource to be the semantics of
                          what the author intends to identify, rather than the value
                          corresponding
                          to those semantics at the time the reference is created. It is then
                          left to the author to ensure that the identifier chosen for a
                          reference does indeed identify the intended semantics.

                          In practice, multilingual sites rarely place equivalent content in
                          multiple languages on negotiated URIs without an explicit redirect.
                          Aside from the fact that Accept-Charset is rarely configured properly,
                          the fact is that different languages do not produce equivalents.
                          There are hundreds of nuances, colloquialisms, and shared social
                          norms that simply do not translate. We encourage resource owners
                          to only use true content negotiation (without redirects) when the
                          only difference between formats is mechanical in nature.

                          > The situation with HTML and PDF representations of an article, which
                          > you also described, is similar. Although je ne parle pas Francais, I
                          > do use both PDF and HTML, so I can use myself as an example user. I
                          > prefer HTML for on screen reading, but PDF for printing. For longer
                          > written works--article length and longer--I prefer to print and read
                          > on paper. I have printed Roy Fielding's thesis out, for example. I
                          > would have preferred to actually get a PDF version of that thesis for
                          > printing, but I didn't see one.

                          Huh, that is getting to be a FAQ. I have no idea why people can't see
                          the second and third link on the top page

                          http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

                          that point to the two PDF editions. *shrug*

                          > Some things that I can imagine doing as-envisioned content
                          > negotiation on are things that really are information commodities
                          > from the perspective of the user, such as PNG and GIF. Either one you
                          > send should provide the user with the same experience, and the user
                          > probably doesn't care which one the browser uses to construct the
                          > image it displays. So here it seems fine to me to do content
                          > negotiation as envisioned by HTTP. Note that in this case, what you
                          > are really negotiating with is the user agent, not the user.
                          >
                          > One place I'm not sure which way to go is with a version of a URI fit
                          > for small screens, such as Blackberries. I could just adjust the page
                          > when I guess from the request that they are on a small screen, or I
                          > could include a link to a small screen version. But that would really
                          > mean there's two different sets of pages, one for desktop computers
                          > and laptops, and one for mobile devices. I haven't figured out what
                          > to do in this case, but I think that allowing access from mobile
                          > devices will be important, and suspect that just sending the same
                          > thing to big and small screens won't make users happy. I welcome
                          > suggestions.

                          Mobile devices usually have a different set of interesting
                          transitions (links), different artwork, and often different content.
                          I usually treat them the same way as different languages. Note that,
                          like the home page above, the "cool URI" entry points that get
                          published on other sites/email/papers are all negotiated, but result
                          in a redirect to the language+device view of preference.

                          ....Roy
                        • Yannick Loiseau
                          ... I think all the issue here is mainly due to browser limitations, as they doesn t allow the user to easily swith conneg preferences. The more I read
                          Message 12 of 23 , Apr 11, 2006
                          • 0 Attachment
                            Bill Venners wrote:

                            > The problem with the envisioned HTTP/RESTful approach to content
                            > negotiation is that different human language representations of an
                            > article such as French/English, and file format differences such as
                            > HTML/PDF, are not information commodities to users. You can't just
                            > replace one with the other. It does matter to the user which one you
                            > give them, and what they want depends on the situation. The server
                            > needs to negotiate with the *user*, not the user agent, to figure out
                            > what representation they want in each specific situation. For non-
                            > commodities, I believe the best way to do that is to give them a
                            > different URI for each, because then the user can express his or her
                            > wishes with a click.

                            I think all the issue here is mainly due to browser limitations, as they
                            doesn't allow the user to easily swith conneg preferences. The more I
                            read discussions or I am involved in service design, the more I think
                            about making a Firefox extention displaying some info about the
                            available conneg on the page (Accept / Vary header ?) and providing some
                            menu of field to change settings for the current page only. Some
                            extentions already display Header fields, but I'm not aware of a
                            "switcher" extention, except the ones allowing to fully customize
                            header, which is not so user friendly.

                            An other approach to your PDF problem could be the browser set
                            automaticaly the Accept header to "application/postscript,
                            application/pdf, text/html;q=0.8,text/*;q=0.5;*/*;q=0.1" and reGET the
                            page when clicking on "print".

                            For the "send link" and bookmark issue, you can always send a redirect
                            based on conneg, if each version has is own uri.
                          • Bill Venners
                            Bonjour Yannick, ... Well, we d have to do user testing with the actual implementation of your idea. But I can t imagine anything simpler for the user than
                            Message 13 of 23 , Apr 11, 2006
                            • 0 Attachment
                              Bonjour Yannick,

                              On Apr 11, 2006, at 12:15 AM, Yannick Loiseau wrote:
                              >> The problem with the envisioned HTTP/RESTful approach to content
                              >> negotiation is that different human language representations of an
                              >> article such as French/English, and file format differences such as
                              >> HTML/PDF, are not information commodities to users. You can't just
                              >> replace one with the other. It does matter to the user which one you
                              >> give them, and what they want depends on the situation. The server
                              >> needs to negotiate with the *user*, not the user agent, to figure out
                              >> what representation they want in each specific situation. For non-
                              >> commodities, I believe the best way to do that is to give them a
                              >> different URI for each, because then the user can express his or her
                              >> wishes with a click.
                              >
                              > I think all the issue here is mainly due to browser limitations, as
                              > they
                              > doesn't allow the user to easily swith conneg preferences. The more I
                              > read discussions or I am involved in service design, the more I think
                              > about making a Firefox extention displaying some info about the
                              > available conneg on the page (Accept / Vary header ?) and providing
                              > some
                              > menu of field to change settings for the current page only. Some
                              > extentions already display Header fields, but I'm not aware of a
                              > "switcher" extention, except the ones allowing to fully customize
                              > header, which is not so user friendly.
                              >
                              Well, we'd have to do user testing with the actual implementation of
                              your idea. But I can't imagine anything simpler for the user than
                              point and click.

                              > An other approach to your PDF problem could be the browser set
                              > automaticaly the Accept header to "application/postscript,
                              > application/pdf, text/html;q=0.8,text/*;q=0.5;*/*;q=0.1" and reGET the
                              > page when clicking on "print".
                              >
                              Well, the trouble with this is that not every user is like me. I like
                              to print PDF and read HTML on screen, but does everyone? And I don't
                              *always* want to print PDF. Right now in my backpack I have a few
                              chapters of Roy's thesis printed out, chapters 5 and 6 I think,
                              because those were of greatest interest to me. At the time of
                              printing, I didn't want to pay for paper and ink for the others, or
                              carry around the weight and bulk. And in that situation it is
                              actually easier for me to print the two HTML documents for those two
                              chapters, and go into the PDF and figure out which from and to page I
                              want. Having a different URI for each chapter was exactly what I
                              wanted, and exactly what I was given.

                              > For the "send link" and bookmark issue, you can always send a redirect
                              > based on conneg, if each version has is own uri.
                              >
                              This is true, but I think people will tend to send the URL that's in
                              the address bar of the browser, not the one that's listed somewhere
                              as the canonical URL for the content. People will most likely link to
                              one of the non-entry URLs. Hmm. I think I need some terminology. How
                              about "entry URI" for the one that uses conneg to redirect to another
                              "target URI". My untested belief is that people will most likely send
                              in emails the target URI they land on, and put links in their web
                              pages using those target URIs. So search engines will favor the
                              target URIs, not the entry URI. Therefore, people will rarely go to
                              an entry URI. I don't have any plans for using entry URIs. Instead,
                              there are just "target URIs," but the target URIs will use conneg to
                              decide whether to point to each other prominently. The one place
                              where I think an entry URI might work is the example that Roy gave in
                              his earlier email on this thread, which is to the domain home itself,
                              as in:

                              http://www.day.com/

                              People will type that in and go there, and that URL does seem to get
                              indexed by search engines. Otherwise, I'm not sure that the entry URI
                              approach is very useful. Has anyone had success with this other than
                              on the domain home URL?

                              Bill
                              ----
                              Bill Venners
                              Editor-in-Chief
                              Artima Developer
                              http://www.artima.com
                            • Sandeep Shetty
                              Hey Bill, ... Ah! When I said easy I meant consistent/standard. I acknowledge the fact that this is not easy given our current situation especially in
                              Message 14 of 23 , Apr 11, 2006
                              • 0 Attachment
                                Hey Bill,

                                On 4/11/06, Bill Venners <bv-svp@...> wrote:
                                > I would contest your statement, "a client can easily get to the
                                > other format," and suggest that is the main usability problem with
                                > content negotiation as envisioned in the HTTP spec and REST.

                                Ah! When I said "easy" I meant consistent/standard. I acknowledge the
                                fact that this is not easy given our current situation especially in
                                Browersland. I thought I made that clear when I said: "I know what you
                                mean especially from an usability perspective given the current state
                                of affairs..."

                                But nothing stops us from changing this when we are designing REST
                                based services.

                                > In both examples you give, I believe users want to be able to chose
                                > between representations. Most users don't understand request headers,
                                > or how to set their preferences.

                                And they (users not HTTP clients) shouldn't have to.

                                I think there are two ways to provide users with the ability to
                                paramaterize the request:

                                1. If there was someway for the server to tell the client that this
                                resource is also available in these other formats then the clients
                                could make this information available to the user using an appropriate
                                UI widget. The user in turn would click on the format/language he is
                                interested in using the widget and the client would send a request to
                                the server parameterized by the users choice.

                                Example:

                                GET /interview-with-foo
                                Content-Type: text/html
                                Alt-Content-Types: application/pdf


                                2. Another way we could let the user parameterize the request is if we
                                could provide the same info in an attribute of the anchor tag. The
                                client could again make this information available to the user using
                                an appropriate UI widget and allow the user to paramaterize the
                                request with a "click" like you want.

                                Example:
                                <a alt-content-type="application/pdf" href="..

                                If I get the time I might try to implement Firefox extensions for
                                these. But do you guys think this would be the right way to do it? The
                                only problems that I can think of is with caches.


                                Sandeep Shetty
                                http://sandeep.shetty.in
                              • Sandeep Shetty
                                Hey Roy, ... Are you saying that this is the right way to do it or are you saying that we need to do it this way because we dont have much of an option given
                                Message 15 of 23 , Apr 11, 2006
                                • 0 Attachment
                                  Hey Roy,

                                  On 4/11/06, Roy T. Fielding <fielding@...> wrote:
                                  > Whoa, I think this is a case of reading too much into my dissertation.
                                  > The sites that I produce *always* separate languages into separate
                                  > URI trees.

                                  Are you saying that this is the right way to do it or are you saying
                                  that we need to do it this way because we dont have much of an option
                                  given the current infrastructure?


                                  > the fact is that different languages do not produce equivalents.
                                  > There are hundreds of nuances, colloquialisms, and shared social
                                  > norms that simply do not translate. We encourage resource owners
                                  > to only use true content negotiation (without redirects) when the
                                  > only difference between formats is mechanical in nature.

                                  Are you saying that true content negotiation should only be done for
                                  stuff like changing formats (like when you have a base XML and you
                                  convert it into PDF, HTML, etc.) and not for languages?


                                  Sandeep Shetty
                                  http://sandeep.shetty.in/
                                • Bill Venners
                                  Hello Roy, ... Sorry about that. It is the HTTP/1.1 spec that uses human language as an example in several places when talking about content negotiation. And
                                  Message 16 of 23 , Apr 11, 2006
                                  • 0 Attachment
                                    Hello Roy,

                                    On Apr 10, 2006, at 1:56 PM, Roy T. Fielding wrote:

                                    >> What you describe sound to me like the approach envisioned by the
                                    >> HTTP designers when they designed content negotiation, and in Roy
                                    >> Fielding's dissertation when he discusses REST. I would contest your
                                    >> statement, "a client can easily get to the other format," and suggest
                                    >> that is the main usability problem with content negotiation as
                                    >> envisioned in the HTTP spec and REST.
                                    >
                                    > Whoa, I think this is a case of reading too much into my dissertation.
                                    >
                                    Sorry about that. It is the HTTP/1.1 spec that uses human language as
                                    an example in several places when talking about content negotiation.
                                    And it was rest-discuss, not your dissertation, where I kept having
                                    that message reinforced in the context of REST. In section 12 of the
                                    HTTP/1.1 spec it says:

                                    Note: This is not called "format negotiation" because the alternate
                                    representations may be of the same media type, but use different
                                    capabilities of that type, be in different languages, etc.

                                    But in your dissertation in 6.3.2.7, you actually point out the
                                    usability problem I was trying to highlight:

                                    In preemptive negotiation, the user agent tells the server what it is
                                    capable of accepting. The server is then supposed to select the
                                    representation that best matches what the user agent claims to be its
                                    capabilities. However, this is a non-tractable problem because it
                                    requires not only information on what the UA will accept, but also
                                    how well it accepts each feature and to what purpose the user intends
                                    to put the representation. For example, a user that wants to view an
                                    image on screen might prefer a simple bitmap representation, but the
                                    same user with the same browser may prefer a PostScript
                                    representation if they intend to send it to a printer instead. It
                                    also depends on the user correctly configuring their browser
                                    according to their own personal content preferences. In short, a
                                    server is rarely able to make effective use of preemptive negotiation...

                                    > Huh, that is getting to be a FAQ. I have no idea why people can't see
                                    > the second and third link on the top page
                                    >
                                    > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
                                    >
                                    > that point to the two PDF editions. *shrug*
                                    >
                                    Well, I've looked at that page several times and didn't notice it. It
                                    looks a bit like the preface, and I think my eyes quickly moved to
                                    the table of contents looking for the "good stuff." I've found if you
                                    don't make something big, red, and put it right in the center, even
                                    regular users may not notice it. You might want to put a PDF icon
                                    next to it, and move it over to the right so it doesn't look like the
                                    preface material that people might tend to ignore.

                                    > Mobile devices usually have a different set of interesting
                                    > transitions (links), different artwork, and often different content.
                                    > I usually treat them the same way as different languages. Note that,
                                    > like the home page above, the "cool URI" entry points that get
                                    > published on other sites/email/papers are all negotiated, but result
                                    > in a redirect to the language+device view of preference.
                                    >
                                    Thanks for the advice. It makes sense. My one uncertainty is on the
                                    utility of entry points that only redirect, because I'm not sure how
                                    many people will ever go there. Since everyone who goes there gets
                                    redirected elsewhere, they will probably link to one of the target
                                    pages, not the entry point. So far I've been thinking of having a
                                    default form of the content at what you might otherwise use as the
                                    entry point, and then include on that page a menu of links to the
                                    other forms.

                                    Bill
                                    ----
                                    Bill Venners
                                    Editor-in-Chief
                                    Artima Developer
                                    http://www.artima.com
                                  • Roy T. Fielding
                                    ... I am saying that server-driven negotiation doesn t work very well because different language editions are different resources and deserve their own URIs.
                                    Message 17 of 23 , Apr 12, 2006
                                    • 0 Attachment
                                      On Apr 11, 2006, at 10:32 PM, Sandeep Shetty wrote:
                                      > On 4/11/06, Roy T. Fielding <fielding@...> wrote:
                                      >> Whoa, I think this is a case of reading too much into my
                                      >> dissertation.
                                      >> The sites that I produce *always* separate languages into separate
                                      >> URI trees.
                                      >
                                      > Are you saying that this is the right way to do it or are you saying
                                      > that we need to do it this way because we dont have much of an option
                                      > given the current infrastructure?

                                      I am saying that server-driven negotiation doesn't work very well
                                      because different language editions are different resources and
                                      deserve their own URIs. It results in the problems that were already
                                      described and quoted by Bill.

                                      Agent-driven negotiation is far more effective, but there was a huge
                                      disagreement between myself and the chair of the HTTP working group
                                      and my original agent-driven design for HTTP/1.1 was effectively
                                      buried in committee.

                                      To do negotiation right, the client needs to be aware of all the
                                      alternatives *and* what it should use as a bookmark. In HTTP/1.1,
                                      all we managed to standardize is 300 and Vary. We needed Alternates
                                      and Link to make it work.

                                      >> the fact is that different languages do not produce equivalents.
                                      >> There are hundreds of nuances, colloquialisms, and shared social
                                      >> norms that simply do not translate. We encourage resource owners
                                      >> to only use true content negotiation (without redirects) when the
                                      >> only difference between formats is mechanical in nature.
                                      >
                                      > Are you saying that true content negotiation should only be done for
                                      > stuff like changing formats (like when you have a base XML and you
                                      > convert it into PDF, HTML, etc.) and not for languages?

                                      I am saying that all important resources must have URIs.

                                      ....Roy
                                    • Roy T. Fielding
                                      ... That s why there exists a link relation called bookmark. Too bad nobody implemented it. ... Note that blogs also use permalink links to tell the user
                                      Message 18 of 23 , Apr 12, 2006
                                      • 0 Attachment
                                        On Apr 11, 2006, at 11:20 PM, Bill Venners wrote:

                                        > My one uncertainty is on the
                                        > utility of entry points that only redirect, because I'm not sure how
                                        > many people will ever go there. Since everyone who goes there gets
                                        > redirected elsewhere, they will probably link to one of the target
                                        > pages, not the entry point.

                                        That's why there exists a link relation called bookmark.
                                        Too bad nobody implemented it.

                                        > So far I've been thinking of having a
                                        > default form of the content at what you might otherwise use as the
                                        > entry point, and then include on that page a menu of links to the
                                        > other forms.

                                        Note that blogs also use "permalink" links to tell the user
                                        which link should be used for bookmarks or external links.

                                        ....Roy
                                      • Mark Baker
                                        ... I think Larry might have just apologized for that, indirectly at least 8-) http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html Mark. --
                                        Message 19 of 23 , Apr 12, 2006
                                        • 0 Attachment
                                          On 4/12/06, Roy T. Fielding <fielding@...> wrote:
                                          > Agent-driven negotiation is far more effective, but there was a huge
                                          > disagreement between myself and the chair of the HTTP working group
                                          > and my original agent-driven design for HTTP/1.1 was effectively
                                          > buried in committee.

                                          I think Larry might have just apologized for that, indirectly at least 8-)

                                          http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html

                                          Mark.
                                          --
                                          Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                                        • Jerome Louvel
                                          ... Based on my experience with the Restlet tutorial page at http://www.restlet.org/tutorial I initially had three versions: HTML, PDF and Word referenced from
                                          Message 20 of 23 , Apr 13, 2006
                                          • 0 Attachment
                                            Bill Venners wrote:
                                            > People will type that in and go there, and that URL does seem to get
                                            > indexed by search engines. Otherwise, I'm not sure that the entry URI
                                            > approach is very useful. Has anyone had success with this other than
                                            > on the domain home URL?

                                            Based on my experience with the Restlet tutorial page at
                                            http://www.restlet.org/tutorial I initially had three versions: HTML,
                                            PDF and Word referenced from the home page. Each one was also
                                            addressable by a more specific URI, for example
                                            http://www.restlet.org/tutorial.pdf Content negotiation is available on
                                            all resources of my site, based on the files available and on their
                                            extensions: PDF, HTML, DOC map to the correct media type, EN and FR map
                                            to the correct language, etc. In addition, media type and language
                                            extensions can be combined.

                                            One problem I had was that I didn't test all the links with Internet
                                            Explorer as I'm using Firefox... Unfortunately, IE gives a higher
                                            priority to Word media type than to HTML! See IE accept header:
                                            "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
                                            application/x-shockwave-flash, application/vnd.ms-excel,
                                            application/msword, application/vnd.ms-powerpoint, */*"

                                            To me the best practice seems to be:
                                            1) Use cool URIs (aka entry URI, aka permalink) wherever possible,
                                            especially for entry pages like home pages
                                            2) When a cool URI is requested, be very careful about the pretended
                                            preferences of the user agent (see issue with IE) and try to return the
                                            best representation available, generally in HTML.
                                            3) In the cool representation, add links in a prominent place allowing
                                            the user to reach alternate representations. Based on the current
                                            language, add links to alternate formats available in this language.
                                            Also add links to alternate languages for the HTML format.
                                            4) If a user follows a more specific URI (aka target URI), then also add
                                            a link back to the cool URI (aka permalink).

                                            The expected results are:
                                            1) If cool URIs are correctly implemented, they should return a
                                            satisfying representation in "80%" of cases without requiring additional
                                            action from the user. Also, bookmarks will point to the cool URI.
                                            2) As more specific URIs are available, users are not limited by their
                                            user agent preferences and can easily select the best representation for
                                            them, which can change depending on the context as Bill explained. Users
                                            can also bookmark these specific URIs.
                                            3) Finally, in the 20% of cases where the user selected a specific URI,
                                            he always has the cool URI/permalink available if he wants to share the
                                            URI with other users.

                                            --
                                            Jerome Louvel
                                            http://www.restlet.org
                                          • Alan Dean
                                            ... I feel quite comfortable with the concept of properly supporting Content-Type in the request header but also permitting what is, in effect, an overload
                                            Message 21 of 23 , Apr 14, 2006
                                            • 0 Attachment
                                              --- In rest-discuss@yahoogroups.com, Roy T. Fielding <fielding@...> wrote:

                                              > * snip *
                                              >
                                              > Huh, that is getting to be a FAQ. I have no idea why people can't see
                                              > the second and third link on the top page
                                              >
                                              > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
                                              >
                                              > that point to the two PDF editions. *shrug*
                                              >
                                              > * snip *

                                              I feel quite comfortable with the concept of properly supporting
                                              Content-Type in the request header but also permitting what is, in
                                              effect, an overload from the URL as described by Roy.

                                              However, I have been musing over a real-world issue that is not
                                              illuminated by the HTML / PDF examples discussed. Here is the problem
                                              domain that I have been considering.

                                              Forgive the lengthy nature of this, but I simply want to make my
                                              musing clear.

                                              For argument sake, let's say we are building a blogging engine. We
                                              have decided that we will represent a blog as a resource in the form:

                                              http://example.com/blog/user.name

                                              You decide that the following requests:

                                              GET /blog/user.name HTTP/1.1
                                              Host: example.com
                                              Accept: text/html

                                              and:

                                              GET /blog/user.name HTTP/1.1
                                              Host: example.com
                                              Accept: text/*

                                              and:

                                              GET /blog/user.name HTTP/1.1
                                              Host: example.com
                                              Accept: */*

                                              are all equivalent and resolve to the same response:

                                              HTTP/1.1 200 OK
                                              Content-Type: text/html
                                              <html> ... </html>

                                              All well and good so far...

                                              Now let's consider that we decide to support RSS and Atom xml feeds.
                                              We decide to support the following request:

                                              GET /blog/user.name HTTP/1.1
                                              Host: example.com
                                              Accept: application/rss+xml

                                              to which we provide the response:

                                              HTTP/1.1 200 OK
                                              Content-Type: application/rss+xml
                                              <rss version="2.0"> ... </rss>

                                              However... it turns out that browsers don't recognise
                                              "application/rss+xml" so... we send this response instead:

                                              HTTP/1.1 200 OK
                                              Content-Type: text/xml
                                              <rss version="2.0"> ... </rss>

                                              By the same logic, in the event of the following request:

                                              GET /blog/user.name HTTP/1.1
                                              Host: example.com
                                              Accept: application/atom+xml

                                              We respond:

                                              HTTP/1.1 200 OK
                                              Content-Type: text/xml
                                              <feed xmlns="xmlns="http://www.w3.org/2005/Atom"> ... </feed>


                                              My question is this: that the 'transmutation' of media type doesn't
                                              feel very 'correct' to me. The client is requesting one media type
                                              specifically, but we would then be supplanting the requested type. Do
                                              we just need to live with the reality of browser support, or have I
                                              missed something?


                                              For the record, I would expect 'overloaded' media type requests to
                                              require a matching Accept header as in:

                                              GET /blog/user.name?media=application/atom+xml HTTP/1.1
                                              Host: example.com
                                              Accept: */*

                                              or:

                                              GET /blog/user.name?media=application/rss+xml&version=2.0 HTTP/1.1
                                              Host: example.com
                                              Accept: application/*

                                              My musing was kicked off by this article from the "Microsoft Team RSS
                                              Blog" (see http://blogs.msdn.com/rssteam/articles/PublishersGuide.aspx
                                              ). I worry that we end up in a cul-de-sac where we either do
                                              non-compliant things like media type transformations or end up driving
                                              all 'fuzzy types' onto the URL and smacking down non-compliant
                                              requests with "Bad Request" which is a brittle interoperability
                                              approach. The problem is that the latter approach, whilst being more
                                              tolerant, in effect deprecates the Content-Type header simply due to
                                              poor client support.

                                              Alan Dean
                                              Lead Developer, OnlineTravel.com
                                            • Sandeep Shetty
                                              Hey Roy, ... Here s some stuff I found on these for the others like me who weren t around during the formative days: [1] [2] [3] [4] Looks like I had almost
                                              Message 22 of 23 , Apr 15, 2006
                                              • 0 Attachment
                                                Hey Roy,

                                                On 4/13/06, Roy T. Fielding <fielding@...> wrote:
                                                > To do negotiation right, the client needs to be aware of all the
                                                > alternatives *and* what it should use as a bookmark. In HTTP/1.1,
                                                > all we managed to standardize is 300 and Vary. We needed Alternates
                                                > and Link to make it work.

                                                Here's some stuff I found on these for the others like me who weren't
                                                around during the formative days: [1] [2] [3] [4]

                                                Looks like I had almost started off on a similar path [5] :)


                                                > >> the fact is that different languages do not produce equivalents.
                                                > >> There are hundreds of nuances, colloquialisms, and shared social
                                                > >> norms that simply do not translate. We encourage resource owners
                                                > >> to only use true content negotiation (without redirects) when the
                                                > >> only difference between formats is mechanical in nature.
                                                > >
                                                > > Are you saying that true content negotiation should only be done for
                                                > > stuff like changing formats (like when you have a base XML and you
                                                > > convert it into PDF, HTML, etc.) and not for languages?
                                                >
                                                > I am saying that all important resources must have URIs.

                                                Guess what I'm really asking is this:
                                                I know that we don't have a lot of support for reactive (agent-driven)
                                                negotiation, but if we had, would you still give different language
                                                versions/formats of the same resource different URI's?


                                                Sandeep Shetty
                                                http://sandeep.shetty.in

                                                [1] http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997SepDec/0005.html
                                                [2] http://www.ietf.org/rfc/rfc2068.txt (12.2, 19.6.2.1, 19.6.2.4)
                                                [3] http://www.hpl.hp.com/personal/ange/archives/archives-96/http-wg-archive/1771.html
                                                [4] http://www.nyct.net/~aray/htmlwg/95q3/790.html
                                                [5] http://groups.yahoo.com/group/rest-discuss/message/5885
                                              • chandrasing_patil
                                                ... Entire discussion is about whether representation meta data be addressed via Accept headers than through query string. If I am wrong just leave it at this
                                                Message 23 of 23 , May 2, 2006
                                                • 0 Attachment
                                                  --- In rest-discuss@yahoogroups.com, "Roy T. Fielding" <fielding@...>
                                                  wrote:
                                                  >
                                                  > On Apr 11, 2006, at 10:32 PM, Sandeep Shetty wrote:
                                                  > > On 4/11/06, Roy T. Fielding <fielding@...> wrote:
                                                  > >> Whoa, I think this is a case of reading too much into my
                                                  > >> dissertation.
                                                  > >> The sites that I produce *always* separate languages into separate
                                                  > >> URI trees.
                                                  > >
                                                  > > Are you saying that this is the right way to do it or are you saying
                                                  > > that we need to do it this way because we dont have much of an option
                                                  > > given the current infrastructure?
                                                  >
                                                  > I am saying that server-driven negotiation doesn't work very well
                                                  > because different language editions are different resources and
                                                  > deserve their own URIs. It results in the problems that were already
                                                  > described and quoted by Bill.
                                                  >
                                                  > Agent-driven negotiation is far more effective, but there was a huge
                                                  > disagreement between myself and the chair of the HTTP working group
                                                  > and my original agent-driven design for HTTP/1.1 was effectively
                                                  > buried in committee.
                                                  >
                                                  > To do negotiation right, the client needs to be aware of all the
                                                  > alternatives *and* what it should use as a bookmark. In HTTP/1.1,
                                                  > all we managed to standardize is 300 and Vary. We needed Alternates
                                                  > and Link to make it work.
                                                  >
                                                  > >> the fact is that different languages do not produce equivalents.
                                                  > >> There are hundreds of nuances, colloquialisms, and shared social
                                                  > >> norms that simply do not translate. We encourage resource owners
                                                  > >> to only use true content negotiation (without redirects) when the
                                                  > >> only difference between formats is mechanical in nature.
                                                  > >
                                                  > > Are you saying that true content negotiation should only be done for
                                                  > > stuff like changing formats (like when you have a base XML and you
                                                  > > convert it into PDF, HTML, etc.) and not for languages?
                                                  >
                                                  > I am saying that all important resources must have URIs.
                                                  >
                                                  > ....Roy
                                                  >

                                                  Entire discussion is about whether representation meta data be
                                                  addressed via Accept headers than through query string. If I am wrong
                                                  just leave it at this point itself.

                                                  Resource can be reached by some URI, and kind of representation
                                                  returned depends what kind of representation is requested by reading
                                                  Accept-headers. Even if there are more than one representations
                                                  available, ideally they all represent same state of a resource. If we
                                                  split the URI space with respect to different languages to address the
                                                  localization issue, it may lead to peculiar problems. One of which I
                                                  would like to specifically point out is *Authorization*.

                                                  Normally we to build authorization for resources rather than
                                                  representations (Please correct me if I am wrong). If we build
                                                  application with URI name space splitting for localization, then it
                                                  may happen for example, that French speaking people are able to access
                                                  an URI which English speaking people are not able to access.

                                                  Example:
                                                  English speaking people accessing user information
                                                  http://www.example.com/user/abc?lang=en

                                                  French speaking people accessing user information
                                                  http://www.example.com/user/abc?lang=fr

                                                  Authorization system must use complete URI to authorize the
                                                  request, one just can't drop the query string to get the URI
                                                  http://www.example.com/user/abc because query string parametrizes the
                                                  resource and may have some application specific parameters. One can
                                                  discard the lang parameter of the query string, but isn't that
                                                  unnecessary programming effort? What if there are alternate
                                                  representations available like HTML, pdf, text, etc.? then this
                                                  problem just compounds making the application more complex
                                                  unnecessarily. Instead if Accept headers are used, URI is same across
                                                  any locale or representation. and it becomes very easy to administer
                                                  the authorization.

                                                  One issue I am not able to address though is bit representation
                                                  specific, something like pdf version is only available to specific
                                                  people (like people who pay for that service).

                                                  I am still a novice to ReST, so lack the ReST vocabulary. And I
                                                  spammed someones mailbox (I think twice), I guess. Sorry for the same.
                                                  I just did not check the To select box.
                                                Your message has been successfully submitted and would be delivered to recipients shortly.