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

Prefetching VS HATEOAS

Expand Messages
  • Shea Levy
    Hi all, Often when designing REST interfaces for relational resources, I run into a tension between the efficiency of prefetching a related resource when one
    Message 1 of 4 , Apr 17, 2013
    • 0 Attachment
      Hi all,

      Often when designing REST interfaces for relational resources, I run
      into a tension between the efficiency of prefetching a related resource
      when one is requested on the one hand and the simplicity, elegance, and
      generality of referencing related resources via hypermedia. Does anyone
      have any advice on how best to manage that tension?

      Thanks,
      Shea Levy
    • Erik Wilde
      hello shea. ... maybe i am misreading what you re saying, but i don t really see a tension in the sense of a conflict, more a design trade-off. prefetching is
      Message 2 of 4 , Apr 17, 2013
      • 0 Attachment
        hello shea.

        On 2013-04-17 12:13 , Shea Levy wrote:
        > Often when designing REST interfaces for relational resources, I run
        > into a tension between the efficiency of prefetching a related resource
        > when one is requested on the one hand and the simplicity, elegance, and
        > generality of referencing related resources via hypermedia. Does anyone
        > have any advice on how best to manage that tension?

        maybe i am misreading what you're saying, but i don't really see a
        tension in the sense of a conflict, more a design trade-off. prefetching
        is on the implementation level (it seems), and you would prefetch
        something based on the assumption that a request to a linked resource
        would be received soon, right? the tricky part probably is to avoid
        making prefetching stateful, assuming that the request for the related
        resource will be processed by the same server (if you have more than
        one). so if you make prefetching stateful, you run the risk of making it
        unlikely to actually provide you the benefit it can provide in a more
        stateful setting. so i guess in the end my answer would be: don't start
        implementing stateful patterns based on perceived performance benefits
        that rely on your service behaving in a stateful way.

        cheers,

        dret.

        --
        erik wilde | mailto:dret@... - tel:+1-510-2061079 |
        | UC Berkeley - School of Information (ISchool) |
        | http://dret.net/netdret http://twitter.com/dret |
      • Shea Levy
        ... I hadn t heard of that, thanks! Though it does still require an extra HTTP request, so in high-volume performance-critical stuff it might lose out to a
        Message 3 of 4 , Apr 17, 2013
        • 0 Attachment
          On 04/17/2013 03:20 PM, Nathan Sharfi wrote:
          > On Apr 17, 2013, at 12:13 PM, Shea Levy <shea.levy@...> wrote:
          >
          >> Hi all,
          >>
          >> Often when designing REST interfaces for relational resources, I run
          >> into a tension between the efficiency of prefetching a related resource
          >> when one is requested on the one hand and the simplicity, elegance, and
          >> generality of referencing related resources via hypermedia. Does anyone
          >> have any advice on how best to manage that tension?
          >>
          >> Thanks,
          >> Shea Levy
          > The two don't seem to be in conflict with each other; Firefox has supported <link rel='prefetch' href='…'> for quite a while now. Do you have a different use in mind?
          I hadn't heard of that, thanks! Though it does still require an extra
          HTTP request, so in high-volume performance-critical stuff it might lose
          out to a completely server-side prefetch.
        • Shea Levy
          ... Well, yes and no. I was specifically thinking of a server-side prefetch, where a single request returns multiple resources (rather than a client
          Message 4 of 4 , Apr 17, 2013
          • 0 Attachment
            On 04/17/2013 03:21 PM, Erik Wilde wrote:
            > hello shea.
            >
            > On 2013-04-17 12:13 , Shea Levy wrote:
            >> Often when designing REST interfaces for relational resources, I run
            >> into a tension between the efficiency of prefetching a related resource
            >> when one is requested on the one hand and the simplicity, elegance, and
            >> generality of referencing related resources via hypermedia. Does anyone
            >> have any advice on how best to manage that tension?
            >
            > maybe i am misreading what you're saying, but i don't really see a
            > tension in the sense of a conflict, more a design trade-off.
            > prefetching is on the implementation level (it seems)

            Well, yes and no. I was specifically thinking of a server-side prefetch,
            where a single request returns multiple resources (rather than a client
            intelligently pulling more than it needs). That's a difference in
            interface, not just implementation.

            > , and you would prefetch something based on the assumption that a
            > request to a linked resource would be received soon, right? the tricky
            > part probably is to avoid making prefetching stateful, assuming that
            > the request for the related resource will be processed by the same
            > server (if you have more than one). so if you make prefetching
            > stateful, you run the risk of making it unlikely to actually provide
            > you the benefit it can provide in a more stateful setting. so i guess
            > in the end my answer would be: don't start implementing stateful
            > patterns based on perceived performance benefits that rely on your
            > service behaving in a stateful way.
            >
            > cheers,
            >
            > dret.
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.