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

Re: [rest-discuss] Interface for non-idempotent fetch?

Expand Messages
  • Keith Gaughan
    ... As long as you don t depend on Y returning any particular value, sure it s RESTful, just like when you were using two separate resources above. The value
    Message 1 of 50 , Apr 12, 2007
    • 0 Attachment
      Chuck Hinson wrote:

      > Some resource algebra...
      >
      > Suppose I have two resources X and Y where X is some arbitrary
      > resource and Y is a resource that is a count of the number of GET
      > requests processed by resource X.
      >
      > So, if I do a GET on Y, a get back a count of the number of GET
      > requests processed by resource X.
      >
      > With respect to a RESTful system, this seems like a reasonable thing to do.
      >
      > Suppose X = Y (replace all occurrences of X with Y). We can then
      > define Y as being a resource that is a count of the number of GET
      > requests processed by Y.
      >
      > Is this usage no longer RESTful?

      As long as you don't depend on Y returning any particular value, sure it's
      RESTful, just like when you were using two separate resources above. The
      value returned by Y can only be used as a (very rough) approximation of how
      many GETs were made.

      But frankly, you're better off treating GETs like pure functions.

      K.

      --
      Blacknight Internet Solutions Ltd. <http://blacknight.ie/>
      Unit 12A Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland
      Company No.: 370845
    • Jon Hanna
      ... Agreed. I think another possibility is where something happens in reaction to the GET, but the client isn t necessarily aware that this is how it is
      Message 50 of 50 , Apr 16, 2007
      • 0 Attachment
        Keith Gaughan wrote:
        > Bill de hOra wrote:
        >
        >> Keith Gaughan wrote:
        >>
        >>> That's not to say that performing a GET on a resource _can't_ have
        >>> side-effects, but those side-effects have to be such that if they went away
        >>> the application's functionality would not be changed. That's one of the
        >>> primary REST constraints in HTTP.
        >> Not quite; that treads close to implementation dependence. GET safety is
        >> about accountability. You can't stop server owners doing stupid things
        >> in their implementations, but you can assume it won't be your fault when
        >> they do.
        >
        > In my own awkward way, that's part of what I was trying to say. The kind of
        > side-effects I was thinking of as OK would be things like logging requests:
        > it's a side effect, but it's not externally visible and if the server
        > stopped doing it, the client would know none the better.

        Agreed. I think another possibility is where something happens in
        reaction to the GET, but the client isn't necessarily aware that this is
        how it is happening - e.g the ID generation you discussed earlier could
        be performed by incrementing a counter on GET but could also be
        performed by some sort of UUID algorithm. As long as the semantics of
        the resource are are "ID generator that guarantees uniqueness -
        representation gives current state" rather than "Next in series" then
        the fact that an increment is happening on GET is just an implementation
        artefact that doesn't concern the client.
      Your message has been successfully submitted and would be delivered to recipients shortly.