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

ETag and resource representations

Expand Messages
  • Hubert A Le Van Gong
    Greetings, I have a question about associating ETag to resources in a REST-based architecture. Would you recommend associating a single ETag to the canonical
    Message 1 of 8 , Aug 13, 2013
    • 0 Attachment
      Greetings,

      I have a question about associating ETag to resources in a REST-based architecture.
      Would you recommend associating a single ETag to the canonical (i.e. complete) resource or rather use a different ETag for each representations of said resource.
      For instance, if I consider a library (full of books) as a resource. The view of that resource (i.e. the list of books returned) may vary based on the age of the reader (or any other criteria). Should I consider one ETag for the library as a whole or should I create an ETag for each representation returned to each reader?

      Maybe another way to ask the same question: should the ETag management solely be based on the resource or also influenced by other factors surrounding requests for it (e.g. policies etc.)?

      Cheers,
      Hubert
    • Jan Algermissen
      Hubert, ... ETag applies to the representation. If the actual bytes of the representation differ the ETag must differ. Jan
      Message 2 of 8 , Aug 14, 2013
      • 0 Attachment
        Hubert,

        On 14.08.2013, at 03:11, Hubert A Le Van Gong <hubertlvg@...> wrote:

        > Greetings,
        >
        > I have a question about associating ETag to resources in a REST-based architecture.
        > Would you recommend associating a single ETag to the canonical (i.e. complete) resource or rather use a different ETag for each representations of said resource.
        > For instance, if I consider a library (full of books) as a resource. The view of that resource (i.e. the list of books returned) may vary based on the age of the reader (or any other criteria). Should I consider one ETag for the library as a whole or should I create an ETag for each representation returned to each reader?
        >

        ETag applies to the representation. If the actual bytes of the representation differ the ETag must differ.

        Jan


        > Maybe another way to ask the same question: should the ETag management solely be based on the resource or also influenced by other factors surrounding requests for it (e.g. policies etc.)?
        >
        > Cheers,
        > Hubert
        >
        >
      • Erik Wilde
        hello jan. ... that s correct for strong ETags (the default), but not the case for weak ETags (which a server can choose to use).
        Message 3 of 8 , Aug 14, 2013
        • 0 Attachment
          hello jan.

          On 2013-08-14 16:11 , Jan Algermissen wrote:
          > On 14.08.2013, at 03:11, Hubert A Le Van Gong <hubertlvg@...> wrote:
          >> I have a question about associating ETag to resources in a REST-based architecture.
          >> Would you recommend associating a single ETag to the canonical (i.e. complete) resource or rather use a different ETag for each representations of said resource.
          >> For instance, if I consider a library (full of books) as a resource. The view of that resource (i.e. the list of books returned) may vary based on the age of the reader (or any other criteria). Should I consider one ETag for the library as a whole or should I create an ETag for each representation returned to each reader?
          > ETag applies to the representation. If the actual bytes of the representation differ the ETag must differ.

          that's correct for strong ETags (the default), but not the case for weak
          ETags (which a server can choose to use).

          http://tools.ietf.org/html/rfc2616#section-13.3.3

          i'd say that weak ETags are mostly used to have ETags survive
          non-essential differences (hit counters are the canonical example). it
          would be interesting to hear whether services are using them for other
          purposes like the one hubert mentioned.

          cheers,

          dret.

          --
          erik wilde | mailto:dret@... - tel:+1-510-2061079 |
          | UC Berkeley - School of Information (ISchool) |
          | http://dret.net/netdret http://twitter.com/dret |
        • Jan Algermissen
          ... Ahr yes, forgot these - thanks for point that out. For a deeper discussion: http://www.mnot.net/blog/2007/08/07/etags Jan
          Message 4 of 8 , Aug 14, 2013
          • 0 Attachment
            On 14.08.2013, at 16:23, Erik Wilde <dret@...> wrote:

            > hello jan.
            >
            > On 2013-08-14 16:11 , Jan Algermissen wrote:
            >> On 14.08.2013, at 03:11, Hubert A Le Van Gong <hubertlvg@...> wrote:
            >>> I have a question about associating ETag to resources in a REST-based architecture.
            >>> Would you recommend associating a single ETag to the canonical (i.e. complete) resource or rather use a different ETag for each representations of said resource.
            >>> For instance, if I consider a library (full of books) as a resource. The view of that resource (i.e. the list of books returned) may vary based on the age of the reader (or any other criteria). Should I consider one ETag for the library as a whole or should I create an ETag for each representation returned to each reader?
            >> ETag applies to the representation. If the actual bytes of the representation differ the ETag must differ.
            >
            > that's correct for strong ETags (the default), but not the case for weak ETags (which a server can choose to use).

            Ahr yes, forgot these - thanks for point that out.

            For a deeper discussion: http://www.mnot.net/blog/2007/08/07/etags

            Jan


            >
            > http://tools.ietf.org/html/rfc2616#section-13.3.3
            >
            > i'd say that weak ETags are mostly used to have ETags survive non-essential differences (hit counters are the canonical example). it would be interesting to hear whether services are using them for other purposes like the one hubert mentioned.
            >
            > cheers,
            >
            > dret.
            >
            > --
            > erik wilde | mailto:dret@... - tel:+1-510-2061079 |
            > | UC Berkeley - School of Information (ISchool) |
            > | http://dret.net/netdret http://twitter.com/dret |
          • Hubert A Le Van Gong
            Jan, Erik, Thanks for your responses; I was afraid you were going to say that (1 ETag per representation) :) In our case, the ecosystem is quite large (many
            Message 5 of 8 , Aug 14, 2013
            • 0 Attachment
              Jan, Erik,

              Thanks for your responses; I was afraid you were going to say that (1 ETag per representation) :)

              In our case, the ecosystem is quite large (many nodes accessing millions of shared resources).
              Assigning 1 ETag to each representation of a resource not only multiplies the number of ETags to manage but it also complicates the invalidation process: instead of simply tracking changes to the bits of the canonical resource we also need to track updates to other part of the systems that may alter the view of the resource for a given node (e.g. policies linked to that resource etc.).

              Maybe we should look into weak validators and determine what semantic changes are acceptable...

              Cheers,
              Hubert


              On Aug 14, 2013, at 7:26 AM, Jan Algermissen <jan.algermissen@...> wrote:

              >
              > On 14.08.2013, at 16:23, Erik Wilde <dret@...> wrote:
              >
              >> hello jan.
              >>
              >> On 2013-08-14 16:11 , Jan Algermissen wrote:
              >>> On 14.08.2013, at 03:11, Hubert A Le Van Gong <hubertlvg@...> wrote:
              >>>> I have a question about associating ETag to resources in a REST-based architecture.
              >>>> Would you recommend associating a single ETag to the canonical (i.e. complete) resource or rather use a different ETag for each representations of said resource.
              >>>> For instance, if I consider a library (full of books) as a resource. The view of that resource (i.e. the list of books returned) may vary based on the age of the reader (or any other criteria). Should I consider one ETag for the library as a whole or should I create an ETag for each representation returned to each reader?
              >>> ETag applies to the representation. If the actual bytes of the representation differ the ETag must differ.
              >>
              >> that's correct for strong ETags (the default), but not the case for weak ETags (which a server can choose to use).
              >
              > Ahr yes, forgot these - thanks for point that out.
              >
              > For a deeper discussion: http://www.mnot.net/blog/2007/08/07/etags
              >
              > Jan
              >
              >
              >>
              >> http://tools.ietf.org/html/rfc2616#section-13.3.3
              >>
              >> i'd say that weak ETags are mostly used to have ETags survive non-essential differences (hit counters are the canonical example). it would be interesting to hear whether services are using them for other purposes like the one hubert mentioned.
              >>
              >> cheers,
              >>
              >> dret.
              >>
              >> --
              >> erik wilde | mailto:dret@... - tel:+1-510-2061079 |
              >> | UC Berkeley - School of Information (ISchool) |
              >> | http://dret.net/netdret http://twitter.com/dret |
              >
            • Nicholas Shanks
              ... This is a different resource from the whole library and should have a different URI, such as /library/?age=child If a child went to /library/ and should
              Message 6 of 8 , Sep 2, 2013
              • 0 Attachment
                On 14 August 2013 02:11, Hubert A Le Van Gong <hubertlvg@...> wrote:

                For instance, if I consider a library (full of books) as a resource. The view of that resource (i.e. the list of books returned) may vary based on the age of the reader (or any other criteria).


                This is a different resource from the whole library and should have a different URI, such as /library/?age=child
                If a child went to /library/ and should not be allowed to see some of the inappropriate books there then either a 401 or 303 should result, not 2xx response with a subset of the results an adult would see, as that breaks caching. (You can jump through hoops to make it work, but changing the URI is better.)

                In my own company's system, I have a resource /jobs that represents the most recent 30 jobs the company has been awarded. The resource /jobs?page=2 represents jobs 31 to 60. We allow our clients to log in to our system, but when they click the View Jobs link, they don't go to /jobs (and only see their own jobs) but to /clients/their-name/jobs Attempts to view other client's jobs URIs result in a 401 (regardless of whether the client exists or not, so as not to leak data).

                Access control coupled with URI proliferation works with the way the web operates. Changing representation based on viewer works against it.


                --
                Nicholas.
              • Hubert A Le Van Gong
                Hi Nicholas, I m not sure why I should consider those as different resources. Isn t that what representations are for? Besides, I m not sure it makes it easier
                Message 7 of 8 , Sep 3, 2013
                • 0 Attachment
                  Hi Nicholas,

                  I'm not sure why I should consider those as different resources. Isn't that what representations are for?
                  Besides, I'm not sure it makes it easier on the caching management side of things as those different resources are nonetheless linked (if an adult purchases a chid book, both the adult library and the child library resources are impacted).

                  Thanks,
                  Hubert

                   

                  On Sep 2, 2013, at 6:17 AM, Nicholas Shanks wrote:

                  On 14 August 2013 02:11, Hubert A Le Van Gong <hubertlvg@...> wrote:

                  For instance, if I consider a library (full of books) as a resource. The view of that resource (i.e. the list of books returned) may vary based on the age of the reader (or any other criteria).


                  This is a different resource from the whole library and should have a different URI, such as /library/?age=child
                  If a child went to /library/ and should not be allowed to see some of the inappropriate books there then either a 401 or 303 should result, not 2xx response with a subset of the results an adult would see, as that breaks caching. (You can jump through hoops to make it work, but changing the URI is better.)

                  In my own company's system, I have a resource /jobs that represents the most recent 30 jobs the company has been awarded. The resource /jobs?page=2 represents jobs 31 to 60. We allow our clients to log in to our system, but when they click the View Jobs link, they don't go to /jobs (and only see their own jobs) but to /clients/their-name/jobs Attempts to view other client's jobs URIs result in a 401 (regardless of whether the client exists or not, so as not to leak data).

                  Access control coupled with URI proliferation works with the way the web operates. Changing representation based on viewer works against it.


                  --
                  Nicholas.

                • Nicholas Shanks
                  ... representations are different presentations/formats/content-types showing the same (sub-)set of data. Page 2 does not contain the same data as page 1, so
                  Message 8 of 8 , Sep 12, 2013
                  • 0 Attachment
                    On 4 September 2013 00:19, Hubert A Le Van Gong <hubertlvg@...> wrote:

                    > Hi Nicholas,
                    >
                    > I'm not sure why I should consider those as different resources. Isn't that
                    > what representations are for?

                    'representations' are different presentations/formats/content-types
                    showing the same (sub-)set of data. Page 2 does not contain the same
                    data as page 1, so isn't a different representation per the http
                    meaning of the noun, but a different resource. The entire library, if
                    not available via a single URL, is not a (HTTP) resource. (Someone
                    please correct me if I'm wrong there.)

                    > Besides, I'm not sure it makes it easier on the caching management side of
                    > things as those different resources are nonetheless linked (if an adult
                    > purchases a chid book, both the adult library and the child library
                    > resources are impacted).

                    The whole goal of a well-written web service is to improve a cache's
                    ability to make a match.
                    You said "The view of that resource (i.e. the list of books returned)
                    may vary based on the age of the reader (or any other criteria)."
                    How are you determining what 'view' to return, or put another way, how
                    do you decide on the "age of the reader"? Are readers users who have
                    to log in and get a cookie set? Or are readers just a target audience
                    for the book, and the client is asking for "children's books" through
                    some query string, the client's age being unknown?
                    If at the moment you're using something like Vary: Cookie to serve
                    different pages to different clients, then your resources are not
                    going to see any caches except the client's browser. Try to eliminate
                    this if at all possible, perhaps via 303 responses to avoid changing
                    the referring href.
                    If you are using query strings to change the books shown, then, as the
                    query string is part of the URL, and the URL is the minimal key
                    required to differentiate resources, a different URL means you are
                    requesting a different resource, and so the URI can be anything you
                    want, e.g. /childrens-books/ or /library?genre=children%39s

                    This isn't really relevant to Entity Tags but I thought I should bring it up.

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