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

How do I RESTfully throw a dice? (or: randomized responses)

Expand Messages
  • Sven Fuchs
    I m sure this is a total noob question but I haven t been able to find an answer :) My beloved has started learning ancient Greek. So I m planning to set up a
    Message 1 of 17 , Feb 1, 2007
    View Source
    • 0 Attachment
      I'm sure this is a total noob question but I haven't been able to
      find an answer :)

      My beloved has started learning ancient Greek. So I'm planning to set
      up a simple vocabulary training program ...

      I imagine a central ressource called "trainer" who's picking
      exercises randomly. A request to the trainer would mean: "give me the
      next exercise you want me to complete". The trainer responds with one
      of many exercises most of the time. After having completed a certain
      number of exercises the trainee would be directed to some kind of
      summary or statistics.

      How should I model this?

      As the response of the trainer ressource is meant to change randomly
      for each request, should I POST to this ressource? Or should I GET it
      and redirect the client through a location header? Or do something
      else that I'm missing?

      This question could probably be reduced to "How do I RESTfully throw
      a dice?"

      Thanks in advance!


      --
      sven fuchs fon: +49 (58 45) 98 89 58
      artweb design fax: +49 (58 45) 98 89 57
      breite straße 65 www: http://www.artweb-design.de
      de-29468 bergen mail: svenfuchs@...
    • Alan Dean
      ... You could implement a dice throw as follows: -- GET /dice/throw
      Message 2 of 17 , Feb 1, 2007
      View Source
      • 0 Attachment
        On 2/1/07, Sven Fuchs <svenfuchs@...> wrote:
        >
        > This question could probably be reduced to "How do I RESTfully throw
        > a dice?"

        You could implement a dice throw as follows:

        -->
        GET /dice/throw

        <--
        302 Found
        Location: /dice/4

        {representation}

        ... perhaps you may want the client to specify the number of sides on the dice:

        -->
        GET /dice/throw/20

        <--
        302 Found
        Location: /dice/11

        {representation}


        Regards, Alan Dean
      • Jon Hanna
        ... Assuming you have no security requirements upon cheating this is a question of one activity (just what that activity is is your very question) mapping to
        Message 3 of 17 , Feb 1, 2007
        View Source
        • 0 Attachment
          Sven Fuchs wrote:
          > This question could probably be reduced to "How do I RESTfully throw
          > a dice?"

          Assuming you have no security requirements upon "cheating" this is a
          question of one activity (just what that activity is is your very
          question) mapping to one of a set of resources.

          Since there is no issue in these resources being independently
          identified they can be identified by URIs that one can GET from and then
          POST answers to.

          The "dice" can indeed be mapped as a redirect. It's perfectly okay to
          map it as a redirect from a GET - that entities returned from resources
          change over time is one of the inherent features of REST and this can
          just as easily be between every single request as it can over more
          clearly marked times of modification.

          Hence a 307 Temporary Redirect from the "dice" resource would be
          apposite. Note that by default 307 responses are not cacheable (which
          suits your purposes) though there is nothing to stop the target of the
          redirect being cached (which is a good thing, if chance does mean a
          repeat on the dice there's no reason why the cache shouldn't be used).

          If you need to guard against cheating then a different model would be
          required beyond a purely simple 307.
        • Mark Baker
          ... How about; GET /trainer - 200 Ok Content-Type: text/uri-list http://example.org/activity/9 Mark. -- Mark Baker. Ottawa, Ontario, CANADA.
          Message 4 of 17 , Feb 1, 2007
          View Source
          • 0 Attachment
            On 2/1/07, Sven Fuchs <svenfuchs@...> wrote:
            > This question could probably be reduced to "How do I RESTfully throw
            > a dice?"

            How about;

            GET /trainer

            ->

            200 Ok
            Content-Type: text/uri-list
            http://example.org/activity/9

            Mark.
            --
            Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
            Coactus; Web-inspired integration strategies http://www.coactus.com
          • S. Mike Dierken
            ... The response is not meant to change randomly - you said ... want me to complete . Until you ve indicated that your state is complete , then the response
            Message 5 of 17 , Feb 1, 2007
            View Source
            • 0 Attachment
              > I imagine a central ressource called "trainer" who's picking
              > exercises randomly. A request to the trainer would mean:
              > "give me the next exercise you want me to complete". The
              > trainer responds with one of many exercises most of the time.
              > After having completed a certain number of exercises the
              > trainee would be directed to some kind of summary or statistics.
              >
              > How should I model this?
              >
              > As the response of the trainer ressource is meant to change
              > randomly for each request, should I POST to this ressource?
              > Or should I GET it and redirect the client through a location
              > header? Or do something else that I'm missing?
              The response is not meant to change randomly - you said "... want me to
              complete". Until you've indicated that your state is 'complete', then the
              response should remain unchanged (in order to take into consideration the
              failure to retrieve the initial response completely).
            • S. Mike Dierken
              Here s another approach - each lesson retrieved has a link to the next lesson. The client decides when it is complete, then retrieves the next lesson. That
              Message 6 of 17 , Feb 1, 2007
              View Source
              • 0 Attachment
                Here's another approach - each lesson retrieved has a link to the next
                lesson. The client decides when it is complete, then retrieves the next
                lesson. That next lesson has yet another link to yet another lesson. And so
                on.

                GET /lessons/99

                200 Ok
                Content-Type: application/socratic.lesson+xml

                <lesson next='/lessons/47'>
                some lessons to be learned
                </lesson>






                > -----Original Message-----
                > From: S. Mike Dierken [mailto:dierken@...]
                > Sent: Thursday, February 01, 2007 9:23 PM
                > To: 'Sven Fuchs'; 'rest-discuss@yahoogroups.com'
                > Subject: RE: [rest-discuss] How do I RESTfully throw a dice?
                > (or: randomized responses)
                >
                > > I imagine a central ressource called "trainer" who's
                > picking exercises
                > > randomly. A request to the trainer would mean:
                > > "give me the next exercise you want me to complete". The trainer
                > > responds with one of many exercises most of the time.
                > > After having completed a certain number of exercises the
                > trainee would
                > > be directed to some kind of summary or statistics.
                > >
                > > How should I model this?
                > >
                > > As the response of the trainer ressource is meant to change
                > randomly
                > > for each request, should I POST to this ressource?
                > > Or should I GET it and redirect the client through a
                > location header?
                > > Or do something else that I'm missing?
                > The response is not meant to change randomly - you said "...
                > want me to complete". Until you've indicated that your state
                > is 'complete', then the response should remain unchanged (in
                > order to take into consideration the failure to retrieve the
                > initial response completely).
                >
                >
              • Sven Fuchs
                Thanks a lot, guys, for all the kind and quite illuminating responses! ... I now have the feeling that I ve asked for something pretty obvious. ;) Using curl
                Message 7 of 17 , Feb 2, 2007
                View Source
                • 0 Attachment
                  Thanks a lot, guys, for all the kind and quite illuminating responses!

                  Am 01.02.2007 um 17:59 schrieb Alan Dean:
                  > You could implement a dice throw as follows:
                  > -->
                  > GET /dice/throw
                  > <--
                  > 302 Found
                  > Location: /dice/4

                  I now have the feeling that I've asked for something pretty obvious. ;)

                  Using curl I've seen that this even seems to be exactly the behavious
                  that Ruby on Rails shows by default when doing a redirect. So as I'm
                  going to use Ruby on Rails that's probably the way for me to go.


                  Am 01.02.2007 um 17:59 schrieb Jon Hanna:
                  > The "dice" can indeed be mapped as a redirect. It's perfectly okay to
                  > map it as a redirect from a GET - that entities returned from
                  > resources
                  > change over time is one of the inherent features of REST and this can
                  > just as easily be between every single request as it can over more
                  > clearly marked times of modification.

                  What initially irritated me (and still does so) was the consideration
                  that GET has to be idempotent. I had the impression that redirecting
                  to different locations would mean issuing entirely different
                  responses (and thus violating GETs idempontence). I suppose I've been
                  wrong on this? But what's the meaning of idempotence than in this case?

                  > Hence a 307 Temporary Redirect from the "dice" resource would be
                  > apposite. Note that by default 307 responses are not cacheable (which
                  > suits your purposes) though there is nothing to stop the target of the
                  > redirect being cached (which is a good thing, if chance does mean a
                  > repeat on the dice there's no reason why the cache shouldn't be used).

                  Do you also agree with the 302 Found response that Alan proposed?
                  Looking at the HTTP spec, am I right that there's no difference
                  between these both responses as far as GET requests are concerned?

                  > If you need to guard against cheating then a different model would be
                  > required beyond a purely simple 307.

                  No, cheating is not a design consideration right now.

                  Thanks again for answering!


                  --
                  sven fuchs fon: +49 (58 45) 98 89 58
                  artweb design fax: +49 (58 45) 98 89 57
                  breite straße 65 www: http://www.artweb-design.de
                  de-29468 bergen mail: svenfuchs@...
                • Sven Fuchs
                  ... Cool :) I ve not been aware of this content-type. I (think I) understand how this kind of response exactly models what I ve been asking for. But as I m
                  Message 8 of 17 , Feb 2, 2007
                  View Source
                  • 0 Attachment
                    Am 01.02.2007 um 19:56 schrieb Mark Baker:
                    > How about;
                    > GET /trainer
                    > ->
                    > 200 Ok
                    > Content-Type: text/uri-list
                    > http://example.org/activity/9

                    Cool :)

                    I've not been aware of this content-type. I (think I) understand how
                    this kind of response exactly models what I've been asking for.

                    But as I'm going to implement this as a web application (using a
                    browser as a client) I right now think that a 302 Found/Location
                    redirect should do it.

                    --
                    sven fuchs fon: +49 (58 45) 98 89 58
                    artweb design fax: +49 (58 45) 98 89 57
                    breite straße 65 www: http://www.artweb-design.de
                    de-29468 bergen mail: svenfuchs@...
                  • Sven Fuchs
                    ... Hmm, yes. That s probably due to my bad English. What I ve meant was that the trainer selects one of many exercises that the trainee is asked to take. An
                    Message 9 of 17 , Feb 2, 2007
                    View Source
                    • 0 Attachment
                      Am 02.02.2007 um 06:23 schrieb S. Mike Dierken:
                      > The response is not meant to change randomly - you said "... want
                      > me to
                      > complete". Until you've indicated that your state is 'complete',
                      > then the
                      > response should remain unchanged (in order to take into
                      > consideration the
                      > failure to retrieve the initial response completely).

                      Hmm, yes. That's probably due to my bad English.

                      What I've meant was that the trainer selects one of many exercises
                      that the trainee is asked to take. An exercise may be as simple as a
                      question with a multiple choice of answers. Where the random-ness
                      (and thus, the dice) comes into play is where the trainer selects an
                      exercise. Though this selection might involve further criteria at
                      some time (e.g. critera based on the trainees learning process), in
                      it's simplest form it is just a pure random selection.

                      When the trainee gives an incorrect answer the chances of this
                      exercise to be re-selected might be increased. Or not. I'm not yet
                      completely sure about this (I'm thinking about some kind of simple
                      flashcard system [1]). But I'm tending to a model where the order of
                      the exercises is unpredictable / shuffles randomly.

                      [1] http://en.wikipedia.org/wiki/Flashcard


                      --
                      sven fuchs fon: +49 (58 45) 98 89 58
                      artweb design fax: +49 (58 45) 98 89 57
                      breite straße 65 www: http://www.artweb-design.de
                      de-29468 bergen mail: svenfuchs@...
                    • Bill de hOra
                      ... To throw a dice, use POST. To find out what the number was, use GET. To cheat, use PUT. cheers Bill
                      Message 10 of 17 , Feb 2, 2007
                      View Source
                      • 0 Attachment
                        Alan Dean wrote:
                        >
                        >
                        > On 2/1/07, Sven Fuchs <svenfuchs@...
                        > <mailto:svenfuchs%40artweb-design.de>> wrote:
                        > >
                        > > This question could probably be reduced to "How do I RESTfully throw
                        > > a dice?"
                        >
                        > You could implement a dice throw as follows:
                        >
                        > -->
                        > GET /dice/throw
                        >
                        > <--
                        > 302 Found
                        > Location: /dice/4
                        >
                        > {representation}

                        To throw a dice, use POST. To find out what the number was, use GET. To
                        cheat, use PUT.

                        cheers
                        Bill
                      • Mark Baker
                        Ok, but you needn t use text/uri-list. text/html would work as well (with lots more content, of course). The point is simply that you can treat the die/dice
                        Message 11 of 17 , Feb 2, 2007
                        View Source
                        • 0 Attachment
                          Ok, but you needn't use text/uri-list. text/html would work as well
                          (with lots more content, of course). The point is simply that you can
                          treat the die/dice as a random data source and therefore a vanilla
                          GET/200 exchange should suffice.

                          On 2/2/07, Sven Fuchs <svenfuchs@...> wrote:
                          > Am 01.02.2007 um 19:56 schrieb Mark Baker:
                          > > How about;
                          > > GET /trainer
                          > > ->
                          > > 200 Ok
                          > > Content-Type: text/uri-list
                          > > http://example.org/activity/9
                          >
                          > Cool :)
                          >
                          > I've not been aware of this content-type. I (think I) understand how
                          > this kind of response exactly models what I've been asking for.
                          >
                          > But as I'm going to implement this as a web application (using a
                          > browser as a client) I right now think that a 302 Found/Location
                          > redirect should do it.
                          >
                          > --
                          > sven fuchs fon: +49 (58 45) 98 89 58
                          > artweb design fax: +49 (58 45) 98 89 57
                          > breite straße 65 www: http://www.artweb-design.de
                          > de-29468 bergen mail: svenfuchs@...
                          >
                          >
                          >
                          >
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >


                          --
                          Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                          Coactus; Web-inspired integration strategies http://www.coactus.com
                        • Paul Downey
                          ... POST /dice/throw - HTTP 1.1 201 Created Location: /dice/throw/90802 Content-type: text/plain 6 ... GET /dice/throw - //an Atom feed of recent throws GET
                          Message 12 of 17 , Feb 2, 2007
                          View Source
                          • 0 Attachment
                            On 2 Feb 2007, at 11:36, Bill de hOra wrote:
                            > To throw a dice, use POST.
                            POST /dice/throw
                            ->
                            HTTP 1.1 201 Created
                            Location: /dice/throw/90802
                            Content-type: text/plain

                            6

                            > To find out what the number was, use GET.
                            GET /dice/throw
                            -> //an Atom feed of recent throws

                            GET /dice/throw/90802
                            -> //the value of an individual throw, as text, HTML, XML,
                            whatever the client asks for

                            > To cheat, use PUT.
                            run away!

                            Paul
                            --
                            http://blog.whatfettle.com


                            --
                            http://blog.whatfettle.com
                          • Jon Hanna
                            ... For a user-throwable die, yes. For an automatic die were the user just sees the thrown result GET the uncacheable result.
                            Message 13 of 17 , Feb 2, 2007
                            View Source
                            • 0 Attachment
                              Bill de hOra wrote:
                              > To throw a dice, use POST. To find out what the number was, use GET. To
                              > cheat, use PUT.

                              For a user-throwable die, yes.

                              For an automatic die were the user just sees the thrown result GET the
                              uncacheable result.
                            • Benjamin Carlyle
                              ... You have mentioned that in its simplest form this is throwing a die, however there seem to be more complex forms involved as well. The trainer may have to
                              Message 14 of 17 , Feb 3, 2007
                              View Source
                              • 0 Attachment
                                On Thu, 2007-02-01 at 15:02 +0100, Sven Fuchs wrote:
                                > I imagine a central ressource called "trainer" who's picking
                                > exercises randomly. A request to the trainer would mean: "give me the
                                > next exercise you want me to complete". The trainer responds with one
                                > of many exercises most of the time. After having completed a certain
                                > number of exercises the trainee would be directed to some kind of
                                > summary or statistics.

                                You have mentioned that in its simplest form this is throwing a die,
                                however there seem to be more complex forms involved as well. The
                                trainer may have to consider what has already been completed in order to
                                make an appropriate decision. That means that the list of what has been
                                completed has to be included explicitly or implicitly in the url.

                                Explicitly (client keeps track of which are completed):
                                http://example.com/thetrainer?completed=1+2+3+4

                                Implicitly (server keeps track of which are completed):
                                http://example.com/thetrainer?student=foo
                                (add authentication details here?)

                                In the client-side case you would likely need to be rewriting hrefs in
                                pages your return to the student to include the list of completed items.
                                In the server-side case you would likely need the client to PUT or POST
                                information about completed courses, possibly in the form of completed
                                exam papers for example.

                                Benjamin.
                              • Sven Fuchs
                                (resending this to the list, sorry for the dupe, Benjamin) ... Yes. :) I ve just tried to reduce the question to the minimum at this point. But of course
                                Message 15 of 17 , Feb 4, 2007
                                View Source
                                • 0 Attachment
                                  (resending this to the list, sorry for the dupe, Benjamin)

                                  Am 03.02.2007 um 22:46 schrieb Benjamin Carlyle:
                                  > You have mentioned that in its simplest form this is throwing a die,
                                  > however there seem to be more complex forms involved as well. The
                                  > trainer may have to consider what has already been completed in
                                  > order to
                                  > make an appropriate decision.

                                  Yes. :)

                                  I've just tried to reduce the question to the minimum at this point.

                                  But of course you're right. The more complex behaviour of the trainer
                                  might even be pretty much predictable when one knows the exact
                                  algorithm hidden here, but at the same time might appear to be
                                  completely random to a user looking from the outside. As far as I
                                  understand REST deals with what is visible from the outside.

                                  > That means that the list of what has been
                                  > completed has to be included explicitly or implicitly in the url.
                                  >
                                  > Explicitly (client keeps track of which are completed):
                                  > http://example.com/thetrainer?completed=1+2+3+4
                                  >
                                  > Implicitly (server keeps track of which are completed):
                                  > http://example.com/thetrainer?student=foo
                                  > (add authentication details here?)
                                  >
                                  > In the client-side case you would likely need to be rewriting hrefs in
                                  > pages your return to the student to include the list of completed
                                  > items.
                                  > In the server-side case you would likely need the client to PUT or
                                  > POST
                                  > information about completed courses, possibly in the form of completed
                                  > exam papers for example.

                                  Yes, absolutely.

                                  I've started implementing this having the server keeping track of the
                                  state.

                                  --
                                  sven fuchs fon: +49 (58 45) 98 89 58
                                  artweb design fax: +49 (58 45) 98 89 57
                                  breite straße 65 www: http://www.artweb-design.de
                                  de-29468 bergen mail: svenfuchs@...
                                • Sven Fuchs
                                  (resending this to the list, sorry for the dupe, Mark) ... Yes :) But what s the advantage here? I m probably not seeing it. I understand that this has the
                                  Message 16 of 17 , Feb 4, 2007
                                  View Source
                                  • 0 Attachment
                                    (resending this to the list, sorry for the dupe, Mark)

                                    Am 02.02.2007 um 13:30 schrieb Mark Baker:
                                    > Ok, but you needn't use text/uri-list. text/html would work as well
                                    > (with lots more content, of course). The point is simply that you can
                                    > treat the die/dice as a random data source and therefore a vanilla
                                    > GET/200 exchange should suffice.

                                    Yes :)

                                    But what's the advantage here? I'm probably not seeing it.

                                    I understand that this has the advantage of decoupeling things even
                                    further than a 302 Found response does in that it (the 200 Ok text/
                                    uri-list) leaves the decision of calling the URI (or doing whatever
                                    else with it) completely to the client.

                                    So, I could see how I would want to use this approach in an (say)
                                    AJAX-based application. But, as I'm planning to go with plain HTML,
                                    the usual browsers etc. ... how would I use this?


                                    > On 2/2/07, Sven Fuchs <svenfuchs@...> wrote:
                                    >> Am 01.02.2007 um 19:56 schrieb Mark Baker:
                                    >>> How about;
                                    >>> GET /trainer
                                    >>> ->
                                    >>> 200 Ok
                                    >>> Content-Type: text/uri-list
                                    >>> http://example.org/activity/9
                                    >>
                                    >> Cool :)
                                    >>
                                    >> I've not been aware of this content-type. I (think I) understand how
                                    >> this kind of response exactly models what I've been asking for.
                                    >>
                                    >> But as I'm going to implement this as a web application (using a
                                    >> browser as a client) I right now think that a 302 Found/Location
                                    >> redirect should do it.
                                    >>
                                    >> --
                                    >> sven fuchs fon: +49 (58 45) 98 89 58
                                    >> artweb design fax: +49 (58 45) 98 89 57
                                    >> breite straße 65 www: http://www.artweb-design.de
                                    >> de-29468 bergen mail: svenfuchs@...
                                    >>
                                    >>
                                    >>
                                    >>
                                    >>
                                    >> Yahoo! Groups Links
                                    >>
                                    >>
                                    >>
                                    >>
                                    >
                                    >
                                    > --
                                    > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                                    > Coactus; Web-inspired integration strategies http://www.coactus.com
                                    >
                                    >
                                    >
                                    > Yahoo! Groups Links
                                    >
                                    >
                                    >

                                    --
                                    sven fuchs fon: +49 (58 45) 98 89 58
                                    artweb design fax: +49 (58 45) 98 89 57
                                    breite straße 65 www: http://www.artweb-design.de
                                    de-29468 bergen mail: svenfuchs@...
                                  • Mark Baker
                                    ... It s more that the client doesn t request the roll as it does with the other approaches; it simply makes observations of the state of the dice on the
                                    Message 17 of 17 , Feb 5, 2007
                                    View Source
                                    • 0 Attachment
                                      On 2/4/07, Sven Fuchs <svenfuchs@...> wrote:
                                      > Am 02.02.2007 um 13:30 schrieb Mark Baker:
                                      > > Ok, but you needn't use text/uri-list. text/html would work as well
                                      > > (with lots more content, of course). The point is simply that you can
                                      > > treat the die/dice as a random data source and therefore a vanilla
                                      > > GET/200 exchange should suffice.
                                      >
                                      > Yes :)
                                      >
                                      > But what's the advantage here? I'm probably not seeing it.
                                      >
                                      > I understand that this has the advantage of decoupeling things even
                                      > further than a 302 Found response does in that it (the 200 Ok text/
                                      > uri-list) leaves the decision of calling the URI (or doing whatever
                                      > else with it) completely to the client.

                                      It's more that the client doesn't request the roll as it does with the
                                      other approaches; it simply makes observations of the state of the
                                      dice on the server.

                                      > So, I could see how I would want to use this approach in an (say)
                                      > AJAX-based application. But, as I'm planning to go with plain HTML,
                                      > the usual browsers etc. ... how would I use this?

                                      Like this, only with more HTML, and (as I understand your needs), the
                                      random value would be turned into a link;

                                      http://www.random.org/cgi-bin/randnum?num=1&min=1&max=6

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