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

Examples of Async Restful services

Expand Messages
  • Unmesh Joshi
    Hi, There are certain situations where modelling services as async is better choice. One of the reasons can be to limit load on the backend services or
    Message 1 of 8 , May 7 10:51 PM
    • 0 Attachment
      Hi,

      There are certain situations where modelling services as async is better choice. One of the reasons can be to limit load on the backend services or databases if the requests involve heavy processing.
      Restful way of creating these services is to return 202 accepted with a URL to poll the result or status of the request.
      While I have read about and seen text book examples of this approach, I don't know of any real life good examples of this. Can someone point me to a good example?

      Thanks,
      Unmesh
    • Shaunak Kashyap
      In this case, I would still return a 202 Accepted (to indicate asynchronous processing). As for how the result of this processing is conveyed to the client, it
      Message 2 of 8 , May 8 4:26 AM
      • 0 Attachment
        In this case, I would still return a 202 Accepted (to indicate asynchronous processing). As for how the result of this processing is conveyed to the client, it could be a via a poll from the client (as you suggest) or a callback to the client (as in the Twilio example) or even both. I'm not sure if the callback approach is necessarily in conflict with the RESTfulness of the API but I'd love to hear more about that from the list.

        Shaunak

        On May 8, 2013, at 3:32 AM, Unmesh Joshi <unmeshjoshi@...> wrote:

        hmm interesting. In general I would expect Restful API to return a URL as reponse to 202 or 201 where client can poll. Accepting a URl to push response doesnt fit that.


        On Wed, May 8, 2013 at 3:24 PM, Shaunak Kashyap <ycombinator@...> wrote:
        Hi Unmesh,

        This may not be exactly what you are looking for but see http://www.twilio.com/docs/api/rest/sending-sms. This API lets an application send an SMS. Twilio's backend perfoms the actual sending of the SMS asynchronously with the API call.

        The API takes as an optional parameter a StatusCallback URI. This is a URI from your application; Twilio will POST to this URI when it has sent (or tried to send) the SMS.

        Hope that helps,

        Shaunak

        --- In rest-discuss@yahoogroups.com, Unmesh Joshi <unmeshjoshi@...> wrote:
        >
        > Hi,
        >
        > There are certain situations where modelling services as async is better
        > choice. One of the reasons can be to limit load on the backend services or
        > databases if the requests involve heavy processing.
        > Restful way of creating these services is to return 202 accepted with a URL
        > to poll the result or status of the request.
        > While I have read about and seen text book examples of this approach, I
        > don't know of any real life good examples of this. Can someone point me to
        > a good example?
        >
        > Thanks,
        > Unmesh
        >




      • Jan Algermissen
        ... Violates stateless server constraint. Jan
        Message 3 of 8 , May 8 7:36 AM
        • 0 Attachment
          On 08.05.2013, at 13:26, Shaunak Kashyap <ycombinator@...> wrote:

          > I'm not sure if the callback approach is necessarily in conflict with the RESTfulness of the API

          Violates stateless server constraint.

          Jan
        • Mike Kelly
          On Wed, May 8, 2013 at 3:36 PM, Jan Algermissen ... Afaik, stateless server is not a constraint.. Cheers, M
          Message 4 of 8 , May 8 7:45 AM
          • 0 Attachment



            On Wed, May 8, 2013 at 3:36 PM, Jan Algermissen <jan.algermissen@...> wrote:
             


            On 08.05.2013, at 13:26, Shaunak Kashyap <ycombinator@...> wrote:

            > I'm not sure if the callback approach is necessarily in conflict with the RESTfulness of the API

            Violates stateless server constraint.


            Afaik, "stateless server" is not a constraint..

            Cheers,
            M
          • Erik Wilde
            ... no it isn t. a PubSub mechanism such as PuSH can be layered on top of a pull-oriented REST architecture with atom without violating any REST constraints.
            Message 5 of 8 , May 8 8:01 AM
            • 0 Attachment
              On 2013-05-08 07:45 , Mike Kelly wrote:
              > On 08.05.2013, at 13:26, Shaunak Kashyap <ycombinator@...
              > <mailto:ycombinator%40gmail.com>> wrote:
              > > I'm not sure if the callback approach is necessarily in conflict
              > with the RESTfulness of the API
              > Violates stateless server constraint.
              > Afaik, "stateless server" is not a constraint..

              no it isn't. a PubSub mechanism such as PuSH can be layered on top of a
              pull-oriented REST architecture with atom without violating any REST
              constraints. PuSH simply failed to properly address subscription
              management, but otherwise had no architectural issues. managing
              subscriptions on the server is fine REST-wise, it's just fairly
              expensive and thus not a style you would want to follow unless that cost
              is justified. on a side note, since the actual messages are nicely
              self-describes messages, PuSH allowed fairly nice optimization for the
              push side of things, by using layered hub setups.

              cheers,

              dret.

              --
              erik wilde | mailto:dret@... - tel:+1-510-2061079 |
              | UC Berkeley - School of Information (ISchool) |
              | http://dret.net/netdret http://twitter.com/dret |
            • Unmesh Joshi
              There are additional advantages of 202 polling pattern. We can use conditional request processing, plus all the benefits of HTTP caching. Are there any
              Message 6 of 8 , May 8 7:27 PM
              • 0 Attachment
                There are additional advantages of 202 polling pattern. We can use conditional request processing, plus all the benefits of HTTP caching.
                Are there any references which discuss practical benefits of 202 polling pattern over PuSH?


                On Wed, May 8, 2013 at 8:31 PM, Erik Wilde <dret@...> wrote:
                On 2013-05-08 07:45 , Mike Kelly wrote:
                    On 08.05.2013, at 13:26, Shaunak Kashyap <ycombinator@...
                    <mailto:ycombinator%40gmail.com>> wrote:
                     > I'm not sure if the callback approach is necessarily in conflict
                    with the RESTfulness of the API
                    Violates stateless server constraint.
                Afaik, "stateless server" is not a constraint..

                no it isn't. a PubSub mechanism such as PuSH can be layered on top of a pull-oriented REST architecture with atom without violating any REST constraints. PuSH simply failed to properly address subscription management, but otherwise had no architectural issues. managing subscriptions on the server is fine REST-wise, it's just fairly expensive and thus not a style you would want to follow unless that cost is justified. on a side note, since the actual messages are nicely self-describes messages, PuSH allowed fairly nice optimization for the push side of things, by using layered hub setups.

                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
                ... Well, it *is* a constraint of REST - see section 5.1.3. However, I agree that you can add pubsub to REST (i.e. WATCH in Waka). So I was wrong there. Jan
                Message 7 of 8 , May 9 4:56 AM
                • 0 Attachment
                  On 08.05.2013, at 17:01, Erik Wilde <dret@...> wrote:

                  > On 2013-05-08 07:45 , Mike Kelly wrote:
                  > > On 08.05.2013, at 13:26, Shaunak Kashyap <ycombinator@...
                  > > <mailto:ycombinator%40gmail.com>> wrote:
                  > > > I'm not sure if the callback approach is necessarily in conflict
                  > > with the RESTfulness of the API
                  > > Violates stateless server constraint.
                  > > Afaik, "stateless server" is not a constraint..
                  >
                  > no it isn't.

                  Well, it *is* a constraint of REST - see section 5.1.3.

                  However, I agree that you can add pubsub to REST (i.e. WATCH in Waka). So I was wrong there.

                  Jan


                  > a PubSub mechanism such as PuSH can be layered on top of a
                  > pull-oriented REST architecture with atom without violating any REST
                  > constraints. PuSH simply failed to properly address subscription
                  > management, but otherwise had no architectural issues. managing
                  > subscriptions on the server is fine REST-wise, it's just fairly
                  > expensive and thus not a style you would want to follow unless that cost
                  > is justified. on a side note, since the actual messages are nicely
                  > self-describes messages, PuSH allowed fairly nice optimization for the
                  > push side of things, by using layered hub setups.
                  >
                  > 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
                  How is creating a send this sms resource on the server any more stateless than creating a send this sms then POST to this URI resource? The client still
                  Message 8 of 8 , Jun 11, 2013
                  • 0 Attachment
                    How is creating a "send this sms" resource on the server any more stateless than creating a "send this sms then POST to this URI" resource?
                    The client still POSTs to a /sms-queue/ collection, though the resource on the server is a few bytes bigger due to an additional callback URI property.

                    The point of statelessness it to enable scalability by moving state to the many clients from the few servers. Since there is already one resource per sms-sending-client (at least) there is no loss of scalability. I see nothing that violates REST here.

                    — Nicholas.


                    On 8 May 2013, at 15:36, Jan Algermissen <jan.algermissen@...> wrote:

                     


                    On 08.05.2013, at 13:26, Shaunak Kashyap <ycombinator@...> wrote:

                    > I'm not sure if the callback approach is necessarily in conflict with the RESTfulness of the API

                    Violates stateless server constraint.

                    Jan

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