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

Interface for non-idempotent fetch?

Expand Messages
  • Eric Busboom
    I m working on a REST interface for a system that doles out unique identifiers. For each request, the caller gives the system a namespace tag, and the system
    Message 1 of 50 , Apr 3, 2007
    • 0 Attachment
      I'm working on a REST interface for a system that doles out unique
      identifiers. For each request, the caller gives the system a
      namespace tag, and the system gives back the next number for that
      namespace.

      So,

      --> GET /numbers/FOO/next
      1 <--

      --> GET /numbers/FOO/next
      2 <--

      --> GET /numbers/BAR/next
      1 <--

      That seems really wrong -- GET should be idempotent, and these
      requests clearly are not. But, I'm also clearly getting, fetching, a
      value.

      How would you implement this interface?

      A similar question to this was asked regarding throwing Dice:
      http://tech.groups.yahoo.com/group/rest-discuss/message/7768

      The dice discussion wandered a bit, but the most substantive
      suggestion seemed to be:
      Use GET
      Return a 302 status and a Location: header, representing the
      numerical result as a URL
      Include the numerical result in the body of the response

      Is there any consensus on this model? I'm still concerned about the
      use of GET, and the use of the Location: header seems superfluous.

      eric.
    • 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.