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

Re: [rest-discuss] Different resource 'views'

Expand Messages
  • Assaf Arkin
    ... How do you do that? Assaf
    Message 1 of 23 , Aug 4 11:36 AM
    • 0 Attachment
      On Mon, Aug 4, 2008 at 11:32 AM, mike amundsen <mca@...> wrote:
      > one thing to keep in mind is that the 'parameterized' URLs are now new
      > items in any cache. That means *invalidating* the /team/cubs?view=csv
      > URL will not necessarily invalidate the ?view=json version.
      >
      > adding parameter versions like this effectively doubles the cache
      > invalidation/update work you need to keep track of.
      >
      > one way to reduce this impact is to use URL rewriters to convert
      > parameterized URLs into 'standards' URLs that carry the requested
      > content-type and process that request instead.

      How do you do that?

      Assaf

      >
      > MikeA
      >
      > On Mon, Aug 4, 2008 at 2:25 PM, Assaf Arkin <assaf@...> wrote:
      >> On Mon, Aug 4, 2008 at 10:27 AM, Bill de hOra <bill@...> wrote:
      >>> Justin Sheehy wrote:
      >>>>
      >>>>
      >>>> On Aug 4, 2008, at 1:02 PM, Griffin Caprio wrote:
      >>>>
      >>>> > /team/cubs?view=csv
      >>>> > /team/cubs?view=json
      >>>>
      >>>> Do both. When the parameter is present, use it to select the media
      >>>> type.
      >>>>
      >>>> When it is not, then fall back to standard conneg.
      >>>>
      >>>> A reasonable way to think about this is that you're always doing
      >>>> standard
      >>>> conneg, but you're using the view parameter to reduce (to 1) the number
      >>>> of available media types for negotiation.
      >>>
      >>> If you have time, I agree with Justin, and ideally you define a ladder
      >>> (as some frameworks do for making locale decisions). HTTP Accept doesn't
      >>> always work, so it's a good idea to have a parameter based option.
      >>> Speaking for myself, I'd implement the parameter switch before
      >>> supporting an Accept header.
      >>
      >> Another reason, if you have a CSV (or JSON or XML or whatever) view
      >> and you know the URL you can check out the output with your Web
      >> browser (or curl or wget). In my experience it was a big time saver,
      >> by itself worth having these URLs around.
      >>
      >> Assaf
      >>
      >>>
      >>> [Fwiw, some mobile systems won't pass the Accept header along, and in
      >>> one case I've heard of, will drop the entire request.]
      >>>
      >>> Bill
      >>>
      >>>
      >>> ------------------------------------
      >>>
      >>> Yahoo! Groups Links
      >>>
      >>>
      >>>
      >>>
      >>
      >> ------------------------------------
      >>
      >> Yahoo! Groups Links
      >>
      >>
      >>
      >>
      >
      >
      >
      > --
      > mca
      > http://amundsen.com/blog/
      >
    • Griffin Caprio
      ... Yes, i forgot to mention the caching concerns in my original email. It s one of the reasons I wanted to stay clear of query string option. ... Hmm, i ve
      Message 2 of 23 , Aug 4 11:44 AM
      • 0 Attachment
        On Aug 4, 2008, at 1:33 PM, mike amundsen wrote:

        > one thing to keep in mind is that the 'parameterized' URLs are now new
        > items in any cache. That means *invalidating* the /team/cubs?view=csv
        > URL will not necessarily invalidate the ?view=json version.
        >
        > adding parameter versions like this effectively doubles the cache
        > invalidation/update work you need to keep track of.
        >
        >
        Yes, i forgot to mention the caching concerns in my original email.
        It's one of the reasons I wanted to stay clear of query string option.

        > one way to reduce this impact is to use URL rewriters to convert
        > parameterized URLs into 'standards' URLs that carry the requested
        > content-type and process that request instead.
        >
        >
        Hmm, i've never done something like that before. Is it safe to mess
        w/ the HTTP headers like that?

        - Griffin

        > MikeA
        >


        >
        >
        > On Mon, Aug 4, 2008 at 2:25 PM, Assaf Arkin <assaf@...>
        > wrote:
        > > On Mon, Aug 4, 2008 at 10:27 AM, Bill de hOra <bill@...>
        > wrote:
        > >> Justin Sheehy wrote:
        > >>>
        > >>>
        > >>> On Aug 4, 2008, at 1:02 PM, Griffin Caprio wrote:
        > >>>
        > >>> > /team/cubs?view=csv
        > >>> > /team/cubs?view=json
        > >>>
        > >>> Do both. When the parameter is present, use it to select the media
        > >>> type.
        > >>>
        > >>> When it is not, then fall back to standard conneg.
        > >>>
        > >>> A reasonable way to think about this is that you're always doing
        > >>> standard
        > >>> conneg, but you're using the view parameter to reduce (to 1) the
        > number
        > >>> of available media types for negotiation.
        > >>
        > >> If you have time, I agree with Justin, and ideally you define a
        > ladder
        > >> (as some frameworks do for making locale decisions). HTTP Accept
        > doesn't
        > >> always work, so it's a good idea to have a parameter based option.
        > >> Speaking for myself, I'd implement the parameter switch before
        > >> supporting an Accept header.
        > >
        > > Another reason, if you have a CSV (or JSON or XML or whatever) view
        > > and you know the URL you can check out the output with your Web
        > > browser (or curl or wget). In my experience it was a big time saver,
        > > by itself worth having these URLs around.
        > >
        > > Assaf
        > >
        > >>
        > >> [Fwiw, some mobile systems won't pass the Accept header along,
        > and in
        > >> one case I've heard of, will drop the entire request.]
        > >>
        > >> Bill
        > >>
        > >>
        > >> ------------------------------------
        > >>
        > >> Yahoo! Groups Links
        > >>
        > >>
        > >>
        > >>
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        >
        > --
        > mca
        > http://amundsen.com/blog/
        >
        >
      • Bill de hOra
        ... In work ;) I asked a while back if we could use accept headers to negotiate formats (for backward compatibility reasons and to avoid having to formally
        Message 3 of 23 , Aug 4 11:46 AM
        • 0 Attachment
          Griffin Caprio wrote:
          > On Aug 4, 2008, at 12:27 PM, Bill de hOra wrote:
          >
          > Bill,
          >> [Fwiw, some mobile systems won't pass the Accept header along, and in
          >> one case I've heard of, will drop the entire request.]
          >>
          >> Bill
          >>
          > This is interesting. Do you remember where you heard this?

          In work ;) I asked a while back if we could use accept headers to
          negotiate formats (for backward compatibility reasons and to avoid
          having to formally version an API). Our handset engineers hit a
          showstopping problem with an intermediary.

          Generally the mobile web is more restricted when it comes to leveraging
          HTTP. For example a good protocol robustness test is to see what happens
          when all headers except Host and Content-Length are removed from requests.

          Bill
        • Bill de hOra
          ... Good point. Also this happens when the parameters are reordered. Bill
          Message 4 of 23 , Aug 4 11:48 AM
          • 0 Attachment
            mike amundsen wrote:
            > one thing to keep in mind is that the 'parameterized' URLs are now new
            > items in any cache. That means *invalidating* the /team/cubs?view=csv
            > URL will not necessarily invalidate the ?view=json version.
            >
            > adding parameter versions like this effectively doubles the cache
            > invalidation/update work you need to keep track of.

            Good point. Also this happens when the parameters are reordered.

            Bill
          • mike amundsen
            I work on the Windows platform and the ISAPI_Rewrite tool offers a RewriteHeader rule: http://www.isapirewrite.com/docs/#RewriteHeader I ve been told you can
            Message 5 of 23 , Aug 4 11:52 AM
            • 0 Attachment
              I work on the Windows platform and the ISAPI_Rewrite tool offers a
              RewriteHeader rule:
              http://www.isapirewrite.com/docs/#RewriteHeader

              I've been told you can use the type|T rule w/ mod_rewrite on Apache, too.
              (RewriteRule ^(.+\.php)s$ $1 [T=application/x-httpd-php-source])

              I will offer that i've only done this a few times, but w/o any
              noticeable problems. For the most part, I stick with pure conneg.

              MikeA

              On Mon, Aug 4, 2008 at 2:36 PM, Assaf Arkin <assaf@...> wrote:
              > On Mon, Aug 4, 2008 at 11:32 AM, mike amundsen <mca@...> wrote:
              >> one thing to keep in mind is that the 'parameterized' URLs are now new
              >> items in any cache. That means *invalidating* the /team/cubs?view=csv
              >> URL will not necessarily invalidate the ?view=json version.
              >>
              >> adding parameter versions like this effectively doubles the cache
              >> invalidation/update work you need to keep track of.
              >>
              >> one way to reduce this impact is to use URL rewriters to convert
              >> parameterized URLs into 'standards' URLs that carry the requested
              >> content-type and process that request instead.
              >
              > How do you do that?
              >
              > Assaf
              >
              >>
              >> MikeA
              >>
              >> On Mon, Aug 4, 2008 at 2:25 PM, Assaf Arkin <assaf@...> wrote:
              >>> On Mon, Aug 4, 2008 at 10:27 AM, Bill de hOra <bill@...> wrote:
              >>>> Justin Sheehy wrote:
              >>>>>
              >>>>>
              >>>>> On Aug 4, 2008, at 1:02 PM, Griffin Caprio wrote:
              >>>>>
              >>>>> > /team/cubs?view=csv
              >>>>> > /team/cubs?view=json
              >>>>>
              >>>>> Do both. When the parameter is present, use it to select the media
              >>>>> type.
              >>>>>
              >>>>> When it is not, then fall back to standard conneg.
              >>>>>
              >>>>> A reasonable way to think about this is that you're always doing
              >>>>> standard
              >>>>> conneg, but you're using the view parameter to reduce (to 1) the number
              >>>>> of available media types for negotiation.
              >>>>
              >>>> If you have time, I agree with Justin, and ideally you define a ladder
              >>>> (as some frameworks do for making locale decisions). HTTP Accept doesn't
              >>>> always work, so it's a good idea to have a parameter based option.
              >>>> Speaking for myself, I'd implement the parameter switch before
              >>>> supporting an Accept header.
              >>>
              >>> Another reason, if you have a CSV (or JSON or XML or whatever) view
              >>> and you know the URL you can check out the output with your Web
              >>> browser (or curl or wget). In my experience it was a big time saver,
              >>> by itself worth having these URLs around.
              >>>
              >>> Assaf
              >>>
              >>>>
              >>>> [Fwiw, some mobile systems won't pass the Accept header along, and in
              >>>> one case I've heard of, will drop the entire request.]
              >>>>
              >>>> Bill
              >>>>
              >>>>
              >>>> ------------------------------------
              >>>>
              >>>> Yahoo! Groups Links
              >>>>
              >>>>
              >>>>
              >>>>
              >>>
              >>> ------------------------------------
              >>>
              >>> Yahoo! Groups Links
              >>>
              >>>
              >>>
              >>>
              >>
              >>
              >>
              >> --
              >> mca
              >> http://amundsen.com/blog/
              >>
              >



              --
              mca
              http://amundsen.com/blog/
            • Aristotle Pagaltzis
              ... But that will fix caching only at the origin server. (Or to be precise, upstream (closer to the origin server) from the point where the URL rewriting is
              Message 6 of 23 , Aug 4 5:52 PM
              • 0 Attachment
                * mike amundsen <mamund@...> [2008-08-04 20:35]:
                > one way to reduce this impact is to use URL rewriters to
                > convert parameterized URLs into 'standards' URLs that carry the
                > requested content-type and process that request instead.

                But that will fix caching only at the origin server. (Or to be
                precise, upstream (closer to the origin server) from the point
                where the URL rewriting is done.) Any intermediaries ahead of
                that point will still cache multiple differently-named versions
                of the resource.

                Theoretically, sending Content-Location should fix this, but
                RFC 2616 does not stipulate that intermediaries use the header
                for any kind of cache invalidation purposes, so probably very
                few, if any, actually do that.

                Regards,
                --
                Aristotle Pagaltzis // <http://plasmasturm.org/>
              • mike amundsen
                Sebastien: ... First I think it it *possible* that folks will create resources that *do* share underlying data that *might* result in the need to invalidate
                Message 7 of 23 , Aug 4 6:00 PM
                • 0 Attachment
                  Sebastien:

                  to you point on cache invalidation:
                  > Again, they are a represnetation of the resource but all exist at their own
                  > urls as they are different documents.
                  >

                  > I do not see how or why a cache should ever invalidate /car.json when it
                  > invalidates /car.html, and this is no different than invalidation rules on
                  > /car?format=json and /car?format=html, or simply /car with Vary:
                  > Content-Type, the same amount of cache is done.
                  >
                  > As far as I know, we have no way to associate or differenciate a resource
                  > and its representations without resorting to assertion tools like rdf, and
                  > it doesnt seem to me those are handled in most http caches these days.

                  First I think it it *possible* that folks will create resources that
                  *do* share underlying data that *might* result in the need to
                  invalidate caches when the underlying data is changed. While you are
                  right - this is nothing new or special, it is something that i think
                  should be considered when designing public resources. In the example
                  that started this thread, I assumed that:
                  /team/cubs?view=csv
                  /team/cubs?view=json
                  did, in fact share the same data and therefore made my comments
                  regarding this case.

                  Second, I agree that, in the above example, each representation is a
                  actually different resource. I also agree that just because two
                  resources *look* like they share the same underlying data, they may
                  not, in fact share the data and should not be assumed to share that
                  data. I also agree they should be treated as their own resources for
                  caching purposes.

                  Thanks for the chance to clear up my remarks.

                  MikeA

                  On Mon, Aug 4, 2008 at 8:41 PM, Sebastien Lambla <seb@...> wrote:
                  > My OpenRasta framework maps the following urls per resource. Here's a small
                  > example
                  >
                  > GET /car
                  > generic url used for content-type negociation.
                  > if the RedirectOnConneg option is enabled, you will get
                  >
                  > 303 SeeOther
                  > Location: /car.html
                  >
                  > otherwise you'll get a 200 with Content-Location: /car.html and the
                  > necessary contenttype and vary headers.
                  >
                  > /car.{type}
                  > type-specific url against which an attempt at content type negociation will
                  > fail. Those are documents rather than resources so won't provide any content
                  > type negociation at all.
                  >
                  > Some formats can have multiple views, html being the prime example.
                  > Alternates are provided in the html documents and in Link: headers (and
                  > sometimes in 300 responses) and follow the pattern
                  > /car;{view}.html
                  >
                  > Again, they are a represnetation of the resource but all exist at their own
                  > urls as they are different documents.
                  >
                  >>>> adding parameter versions like this effectively doubles the cache
                  >>>> invalidation/update work you need to keep track of.
                  >
                  > I do not see how or why a cache should ever invalidate /car.json when it
                  > invalidates /car.html, and this is no different than invalidation rules on
                  > /car?format=json and /car?format=html, or simply /car with Vary:
                  > Content-Type, the same amount of cache is done.
                  >
                  > As far as I know, we have no way to associate or differenciate a resource
                  > and its representations without resorting to assertion tools like rdf, and
                  > it doesnt seem to me those are handled in most http caches these days.
                  >
                  >
                  > Sebastien Lambla
                  >



                  --
                  mca
                  http://amundsen.com/blog/
                • Eric J. Bowman
                  I agree with the others, that you use content negotiation but allow URI parameters to override it, directly returning the desired variant. This works really
                  Message 8 of 23 , Aug 6 2:18 AM
                  • 0 Attachment
                    I agree with the others, that you use content negotiation but allow URI
                    parameters to override it, directly returning the desired variant. This
                    works really well to test the output of conneg systems, without having
                    to muck about with browser settings or use curl. I say parameter, not
                    query, because your URIs don't represent queries -- the output format
                    has always seemed a parameter to me:

                    /team/cubs;view=csv
                    /team/cubs;view=json

                    Note that this gives clean separation between a choice of output
                    format, and any actual query, say the team's current win/loss record:

                    /team/cubs;view=csv?query=record
                    /team/cubs;view=json?query=record

                    In this situation, we don't have to worry about cache aliasing (my term
                    for what's been discussed in this thread re: order of name/value pairs)
                    because RFC 3986 tells us that queries follow parameters. But, if you
                    use more than one parameter or name/value pair in the query, you're into
                    "matrix URI" territory. My solution is to use 301 redirects to re-order
                    requests into their 'proper' form as I define it, because URIs are
                    opaque -- each unique one will create its own cache alias for the same
                    data. Note that some servers will recognize ?view=csv even if you only
                    intend ;view=csv, instead of returning a 404 as appropriate, because
                    anything after the ';' is considered a query string, I forget why...

                    The icing on the cake, if your source data is accessible as XML, is
                    being able to generate any desired output format/media type combination
                    using XSLT's <output/> element. We've implemented a system where
                    ;view= URI parameters may be added at any time, by PUTting a new XSLT
                    file on the server. For example, if I wanted JSON output, I'd PUT an
                    XSLT file named json.xsl on the server. If that file is present, then
                    any request specifying ;view=json would cause the XSLT processor on the
                    server to transform the XML source data using json.xsl to generate JSON
                    output, and parse <output media-type='application/json'/> to set the
                    HTTP header. IOW, this is the sort of thing XSLT is ideal for.

                    -Eric

                    Griffin Caprio wrote:

                    > Hi all,
                    >
                    > I'm curious to know what are doing to allow clients to request
                    > different views of a resource? For example, say I had this resource:
                    >
                    > /team/cubs
                    >
                    > I'd like to represent the resulting resource as HTML, JSON, CSV,
                    > etc.... The easiest way would be to append a "view" query string
                    > value:
                    >
                    > /team/cubs?view=csv
                    > /team/cubs?view=json
                    > ....
                    >
                    > Another option would be to rely on the request HTTP headers sent
                    > from the client. I like this approach from an athestic pov, since
                    > it doesn't muck up the URLs. But it places a big dependency on the
                    > clients being able to correctly set the right headers. Also, some
                    > headers could have more than one value, so you get into situations
                    > where ordering must be figured out. So it seems like the query
                    > string approach is the most deterministic and also the least complex.
                    >
                    > Anybody else have other options?
                    >
                    > Thanks,
                    > Griffin Caprio
                    > http://blog.1530technologies.com
                    > http://www.oreillynet.com/xml/blog/
                    >
                  • Roy T. Fielding
                    ... I don t know of any sane system that uses the query portion to distinguish format-specific resources. Everybody uses name extensions for that purpose.
                    Message 9 of 23 , Aug 6 9:17 PM
                    • 0 Attachment
                      On Aug 6, 2008, at 2:18 AM, Eric J. Bowman wrote:
                      > I agree with the others, that you use content negotiation but allow
                      > URI
                      > parameters to override it, directly returning the desired variant.
                      > This
                      > works really well to test the output of conneg systems, without having
                      > to muck about with browser settings or use curl. I say parameter, not
                      > query, because your URIs don't represent queries -- the output format
                      > has always seemed a parameter to me:
                      >
                      > /team/cubs;view=csv
                      > /team/cubs;view=json
                      >

                      I don't know of any sane system that uses the query portion to
                      distinguish format-specific resources. Everybody uses name
                      extensions for that purpose. There is absolutely no good reason
                      to do the above instead of

                      /team/cubs.csv
                      /team/cubs.json

                      and plenty of reasons to avoid using query syntax.

                      Have a look at Apache Sling for an example.

                      ....Roy
                    • Eric J. Bowman
                      OK, you re right, but only as long as 1:1 mapping between content- type and representation, or a 1:1 mapping between an extension and a format, exist. The
                      Message 10 of 23 , Aug 7 2:35 AM
                      • 0 Attachment
                        OK, you're right, but only as long as 1:1 mapping between content-
                        type and representation, or a 1:1 mapping between an extension and a
                        format, exist. The .csv and .json extensions have no ambiguity; the
                        same can't be said for .html which might be text/html or
                        application/xhtml+xml, or .xml which may be text/xml or application/
                        xml, and so on.

                        A sane system using the query portion, is one which distinguishes
                        between representations rather than output formats, i.e. assume the
                        following both render as JSON:

                        /team/cubs;view=foo
                        /team/cubs;view=bar

                        The alternative being cubs.json and perhaps cubs.txt for the second
                        JSON representation, which introduces ambiguous extensions, which seems
                        like a good reason not to use file extensions, to me.

                        An application may also serve XHTML 1.0, as application/xhtml+xml to
                        compatible clients, and as text/html to other clients. Since there's
                        only one file, its extension is moot, making URI parameters viable to
                        specify the particular output serialization rather than having two
                        copies of the same file, one as .htm and the other as .html...

                        -Eric

                        "Roy T. Fielding" wrote:

                        > On Aug 6, 2008, at 2:18 AM, Eric J. Bowman wrote:
                        > > I agree with the others, that you use content negotiation but
                        > > allow URI
                        > > parameters to override it, directly returning the desired variant.
                        > > This
                        > > works really well to test the output of conneg systems, without
                        > > having to muck about with browser settings or use curl. I say
                        > > parameter, not query, because your URIs don't represent queries --
                        > > the output format has always seemed a parameter to me:
                        > >
                        > > /team/cubs;view=csv
                        > > /team/cubs;view=json
                        > >
                        >
                        > I don't know of any sane system that uses the query portion to
                        > distinguish format-specific resources. Everybody uses name
                        > extensions for that purpose. There is absolutely no good reason
                        > to do the above instead of
                        >
                        > /team/cubs.csv
                        > /team/cubs.json
                        >
                        > and plenty of reasons to avoid using query syntax.
                        >
                        > Have a look at Apache Sling for an example.
                        >
                        > ....Roy
                        >
                      • Bill de hOra
                        ... What would they be? Bill
                        Message 11 of 23 , Aug 7 6:17 AM
                        • 0 Attachment
                          Roy T. Fielding wrote:

                          > I don't know of any sane system that uses the query portion to
                          > distinguish format-specific resources. Everybody uses name
                          > extensions for that purpose. There is absolutely no good reason
                          > to do the above instead of
                          >
                          > /team/cubs.csv
                          > /team/cubs.json
                          >
                          > and plenty of reasons to avoid using query syntax.

                          What would they be?

                          Bill
                        • Subbu Allamaraju
                          ... This could very well be written as /team/cubs.foo /team/cubs.bar I don t mean to say that one is better than the other though. These are syntactic
                          Message 12 of 23 , Aug 7 8:35 AM
                          • 0 Attachment
                            On Aug 7, 2008, at 2:35 AM, Eric J. Bowman wrote:

                            > A sane system using the query portion, is one which distinguishes
                            > between representations rather than output formats, i.e. assume the
                            > following both render as JSON:
                            >
                            > /team/cubs;view=foo
                            > /team/cubs;view=bar
                            >
                            > The alternative being cubs.json and perhaps cubs.txt for the second
                            > JSON representation, which introduces ambiguous extensions, which
                            > seems
                            > like a good reason not to use file extensions, to me.

                            This could very well be written as

                            /team/cubs.foo
                            /team/cubs.bar

                            I don't mean to say that one is better than the other though. These
                            are syntactic variations that have the same tradeoffs.

                            Subbu
                          • Roy T. Fielding
                            ... 1) It interferes with other uses of the query syntax (for queries); 2) It is often controlled by a different subsystem during operations, in a
                            Message 13 of 23 , Aug 7 11:02 AM
                            • 0 Attachment
                              On Aug 7, 2008, at 6:17 AM, Bill de hOra wrote:
                              > Roy T. Fielding wrote:
                              >
                              > > I don't know of any sane system that uses the query portion to
                              > > distinguish format-specific resources. Everybody uses name
                              > > extensions for that purpose. There is absolutely no good reason
                              > > to do the above instead of
                              > >
                              > > /team/cubs.csv
                              > > /team/cubs.json
                              > >
                              > > and plenty of reasons to avoid using query syntax.
                              >
                              > What would they be?
                              >

                              1) It interferes with other uses of the query syntax (for queries);
                              2) It is often controlled by a different subsystem during operations,
                              in a method-specific and implementation-specific manner, which
                              makes it
                              harder to preserve names when the implementation evolves;
                              3) It looks like a query, so some caches don't bother to cache the
                              response because the hit rate is lower than non-query responses;
                              4) It looks like a potentially "unsafe" resource, so some (spineless)
                              spiders won't traverse it and your site will disappear from search
                              engines.

                              ....Roy
                            • Eric J. Bowman
                              ... As to 3 and 4, the design pattern here is one of overriding content negotiation, which in my case at least is not expected to account for a significant
                              Message 14 of 23 , Aug 8 2:55 AM
                              • 0 Attachment
                                >
                                > 3) It looks like a query, so some caches don't bother to cache the
                                > response because the hit rate is lower than non-query responses;
                                > 4) It looks like a potentially "unsafe" resource, so some (spineless)
                                > spiders won't traverse it and your site will disappear from search
                                > engines.
                                >
                                > ....Roy
                                >

                                As to 3 and 4, the design pattern here is one of overriding content
                                negotiation, which in my case at least is not expected to account for a
                                significant percentage of requests. So, having /team/cubs cached and
                                spidered properly seems sufficient, the individual variants' URIs don't
                                really need caching or spidering.

                                -Eric
                              • Bill de hOra
                                ... Looks like friendfeed don t have a sane system. Bill
                                Message 15 of 23 , Aug 17 8:49 AM
                                • 0 Attachment
                                  Roy T. Fielding wrote:
                                  >
                                  >
                                  > On Aug 7, 2008, at 6:17 AM, Bill de hOra wrote:
                                  > > Roy T. Fielding wrote:
                                  > >
                                  > > > I don't know of any sane system that uses the query portion to
                                  > > > distinguish format-specific resources. Everybody uses name
                                  > > > extensions for that purpose. There is absolutely no good reason
                                  > > > to do the above instead of
                                  > > >
                                  > > > /team/cubs.csv
                                  > > > /team/cubs.json
                                  > > >
                                  > > > and plenty of reasons to avoid using query syntax.
                                  > >
                                  > > What would they be?
                                  > >
                                  >
                                  > 1) It interferes with other uses of the query syntax (for queries);
                                  > 2) It is often controlled by a different subsystem during operations,
                                  > in a method-specific and implementation-specific manner, which
                                  > makes it
                                  > harder to preserve names when the implementation evolves;
                                  > 3) It looks like a query, so some caches don't bother to cache the
                                  > response because the hit rate is lower than non-query responses;
                                  > 4) It looks like a potentially "unsafe" resource, so some (spineless)
                                  > spiders won't traverse it and your site will disappear from search
                                  > engines.

                                  Looks like friendfeed don't have a sane system.

                                  Bill
                                • Bill de hOra
                                  ... Or Yahoo pipes. I suspect this has to with UAs in general not doing conneg very well. Bill
                                  Message 16 of 23 , Aug 17 9:07 AM
                                  • 0 Attachment
                                    Bill de hOra wrote:
                                    >
                                    >
                                    > Roy T. Fielding wrote:
                                    > >
                                    > >
                                    > > On Aug 7, 2008, at 6:17 AM, Bill de hOra wrote:
                                    > > > Roy T. Fielding wrote:
                                    > > >
                                    > > > > I don't know of any sane system that uses the query portion to
                                    > > > > distinguish format-specific resources. Everybody uses name
                                    > > > > extensions for that purpose. There is absolutely no good reason
                                    > > > > to do the above instead of
                                    > > > >
                                    > > > > /team/cubs.csv
                                    > > > > /team/cubs.json
                                    > > > >
                                    > > > > and plenty of reasons to avoid using query syntax.
                                    > > >
                                    > > > What would they be?
                                    > > >
                                    > >
                                    > > 1) It interferes with other uses of the query syntax (for queries);
                                    > > 2) It is often controlled by a different subsystem during operations,
                                    > > in a method-specific and implementation-specific manner, which
                                    > > makes it
                                    > > harder to preserve names when the implementation evolves;
                                    > > 3) It looks like a query, so some caches don't bother to cache the
                                    > > response because the hit rate is lower than non-query responses;
                                    > > 4) It looks like a potentially "unsafe" resource, so some (spineless)
                                    > > spiders won't traverse it and your site will disappear from search
                                    > > engines.
                                    >
                                    > Looks like friendfeed don't have a sane system.

                                    Or Yahoo pipes. I suspect this has to with UAs in general not doing
                                    conneg very well.

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