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

Re: [rest-discuss] Asynchronous Web and REST

Expand Messages
  • mike amundsen
    Check out Rohit Khare s[1] Asynchronous, Routed REST with Estimates and decentralized Decision functions (ARRESTED)[2] mca http://amundsen.com/blog/ [1] -
    Message 1 of 6 , Apr 30, 2009
    • 0 Attachment
      Check out Rohit Khare's[1] "Asynchronous, Routed REST with Estimates and decentralized Decision functions (ARRESTED)[2]"

      mca
      http://amundsen.com/blog/

      [1] - http://www.ics.uci.edu/~rohit/
      [2] - http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf



      2009/4/30 António Mota <amsmota@...>
      I was reading some articles about Asynchronous Web, and the question
      popped on my mind, what are the implications of Asynchronous Web on a
      REST-based architecture?

      And I mean that from the architectural point-of-view, not on
      implementations of asynchronous notifications from resources, or other
      similar implementation "tricks".

      What will be the implications on the architectural constraints and
      interface constraints of REST?

      Client/server model
      Stateless protocols
      Caching
      Uniform Interface
      Layering
      Optional Code-on-demand

      Identification of resources
      Manipulation of resources through representations
      Self-descriptive messages
      Hypermedia as the engine of application state.

      _______________________________________________

      Melhores cumprimentos / Beir beannacht / Best regards

      António Manuel dos Santos Mota

      _______________________________________________


      ------------------------------------

      Yahoo! Groups Links

      <*> To visit your group on the web, go to:
         http://groups.yahoo.com/group/rest-discuss/

      <*> Your email settings:
         Individual Email | Traditional

      <*> To change settings online go to:
         http://groups.yahoo.com/group/rest-discuss/join
         (Yahoo! ID required)

      <*> To change settings via email:
         mailto:rest-discuss-digest@yahoogroups.com
         mailto:rest-discuss-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
         rest-discuss-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
         http://docs.yahoo.com/info/terms/


    • amsmota@gmail.com
      I have yet to read that paper (thanks for the link), but for now everything (not much) I found seems to treat some kind of Asynchronous REST as a extension
      Message 2 of 6 , May 1, 2009
      • 0 Attachment
        I have yet to read that paper (thanks for the link), but for now everything (not much) I found seems to treat some kind of "Asynchronous REST" as a extension of the simple request/response scheme, by allowing some kind of "deferred" response, or "notifications".

        I was thinking more in terms of push technology, in which a request can be started by the server instead of the client. What does that to our constraints?

        Client/server model -> breaks (in the sense that client/server being equivalent to request/response)
        Stateless protocols -> breaks? probably not
        Caching -> breaks?
        Uniform Interface -> doesn't necessarily break, but it could
        Layering -> doesn't necessarily break
        Optional Code-on-demand -> definitely doesn't break

        Identification of resources -> doesn't break
        Manipulation of resources through representations -> doesn't break, although the term "manipulation" here may not be the best
        Self-descriptive messages -> doesn't break ?
        Hypermedia as the engine of application state. -> it could break, and it probably will break


        However, if it break some of the constraints you can't call it REST, so basically the question will be: can REST be the architecture style of a Asynchronous Web application, or do we need a "revised" REST" or even a complete new style?


        On May 1, 2009 2:25am, mike amundsen <mamund@...> wrote:
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > Check out Rohit Khare's[1] "Asynchronous, Routed REST with Estimates and decentralized Decision functions (ARRESTED)[2]"
        >
        >
        > mca
        > http://amundsen.com/blog/
        >
        > [1] - http://www.ics.uci.edu/~rohit/
        > [2] - http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf
        >
        >
        >
        >
        >
        > 2009/4/30 António Mota amsmota@...>
        >
        > I was reading some articles about Asynchronous Web, and the question
        >
        > popped on my mind, what are the implications of Asynchronous Web on a
        >
        > REST-based architecture?
        >
        >
        >
        > And I mean that from the architectural point-of-view, not on
        >
        > implementations of asynchronous notifications from resources, or other
        >
        > similar implementation "tricks".
        >
        >
        >
        > What will be the implications on the architectural constraints and
        >
        > interface constraints of REST?
        >
        >
        >
        > Client/server model
        >
        > Stateless protocols
        >
        > Caching
        >
        > Uniform Interface
        >
        > Layering
        >
        > Optional Code-on-demand
        >
        >
        >
        > Identification of resources
        >
        > Manipulation of resources through representations
        >
        > Self-descriptive messages
        >
        > Hypermedia as the engine of application state.
        >
        >
        >
        > _______________________________________________
        >
        >
        >
        > Melhores cumprimentos / Beir beannacht / Best regards
        >
        >
        >
        > António Manuel dos Santos Mota
        >
        >
        >
        > _______________________________________________
        >
        >
        >
        >
        >
        > ------------------------------------
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        > To visit your group on the web, go to:
        >
        >    http://groups.yahoo.com/group/rest-discuss/
        >
        >
        >
        > Your email settings:
        >
        >    Individual Email | Traditional
        >
        >
        >
        > To change settings online go to:
        >
        >    http://groups.yahoo.com/group/rest-discuss/join
        >
        >    (Yahoo! ID required)
        >
        >
        >
        > To change settings via email:
        >
        >    mailto:rest-discuss-digest@yahoogroups.com
        >
        >    mailto:rest-discuss-fullfeatured@yahoogroups.com
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        >
        >    rest-discuss-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to:
        >
        >    http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
      • Bill Burke
        If Asynchronous Web means Servlet 3.0 and async request processing then: IMO, nothing should change for the client. It should be using the HTTP APIs that
        Message 3 of 6 , May 1, 2009
        • 0 Attachment
          If "Asynchronous Web" means Servlet 3.0 and async request processing then:


          IMO, nothing should change for the client. It should be using the HTTP
          APIs that come with the language/platform.

          It should be in some kind of while loop:

          while(true) {

          response = http.get() // probably post since we're consuming messages
          doEvent(response)

          }

          The whole thing about HTTP is to save threads that are blocking. This
          is the real performance benefit of async HTTP. Comet protocols tunnel
          themselves through HTTP by taking advantage of keep alive semantics.
          With these APIs, a client library is required and you're not really
          using HTTP. You're only using it as a connection setup mechanism.
          There are some small performance benefits to this. Once a connection is
          set up, the server doesn't have to re-route incoming requests and can
          just stream messages to the client.


          BTW, I have done some async HTTP abstractions:

          http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1.1-RC2/userguide/html/Asynchronous_HTTP_Request_Processing.html



          amsmota@... wrote:
          >
          >
          >
          > I have yet to read that paper (thanks for the link), but for now
          > everything (not much) I found seems to treat some kind of "Asynchronous
          > REST" as a extension of the simple request/response scheme, by allowing
          > some kind of "deferred" response, or "notifications".
          >
          > I was thinking more in terms of push technology, in which a request can
          > be started by the server instead of the client. What does that to our
          > constraints?
          >
          > Client/server model -> breaks (in the sense that client/server being
          > equivalent to request/response)
          > Stateless protocols -> breaks? probably not
          > Caching -> breaks?
          > Uniform Interface -> doesn't necessarily break, but it could
          > Layering -> doesn't necessarily break
          > Optional Code-on-demand -> definitely doesn't break
          >
          > Identification of resources -> doesn't break
          > Manipulation of resources through representations -> doesn't break,
          > although the term "manipulation" here may not be the best
          > Self-descriptive messages -> doesn't break ?
          > Hypermedia as the engine of application state. -> it could break, and it
          > probably will break
          >
          >
          > However, if it break some of the constraints you can't call it REST, so
          > basically the question will be: can REST be the architecture style of a
          > Asynchronous Web application, or do we need a "revised" REST" or even a
          > complete new style?
          >
          >
          > On May 1, 2009 2:25am, mike amundsen <mamund@...> wrote:
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > > Check out Rohit Khare's[1] "Asynchronous, Routed REST with Estimates
          > and decentralized Decision functions (ARRESTED)[2]"
          > >
          > >
          > > mca
          > > http://amundsen.com/blog/
          > >
          > > [1] - http://www.ics.uci.edu/~rohit/
          > > [2] - http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf
          > >
          > >
          > >
          > >
          > >
          > > 2009/4/30 António Mota amsmota@...>
          > >
          > > I was reading some articles about Asynchronous Web, and the question
          > >
          > > popped on my mind, what are the implications of Asynchronous Web on a
          > >
          > > REST-based architecture?
          > >
          > >
          > >
          > > And I mean that from the architectural point-of-view, not on
          > >
          > > implementations of asynchronous notifications from resources, or other
          > >
          > > similar implementation "tricks".
          > >
          > >
          > >
          > > What will be the implications on the architectural constraints and
          > >
          > > interface constraints of REST?
          > >
          > >
          > >
          > > Client/server model
          > >
          > > Stateless protocols
          > >
          > > Caching
          > >
          > > Uniform Interface
          > >
          > > Layering
          > >
          > > Optional Code-on-demand
          > >
          > >
          > >
          > > Identification of resources
          > >
          > > Manipulation of resources through representations
          > >
          > > Self-descriptive messages
          > >
          > > Hypermedia as the engine of application state.
          > >
          > >
          > >
          > > _______________________________________________
          > >
          > >
          > >
          > > Melhores cumprimentos / Beir beannacht / Best regards
          > >
          > >
          > >
          > > António Manuel dos Santos Mota
          > >
          > >
          > >
          > > _______________________________________________
          > >
          > >
          > >
          > >
          > >
          > > ------------------------------------
          > >
          > >
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > > To visit your group on the web, go to:
          > >
          > > http://groups.yahoo.com/group/rest-discuss/
          > >
          > >
          > >
          > > Your email settings:
          > >
          > > Individual Email | Traditional
          > >
          > >
          > >
          > > To change settings online go to:
          > >
          > > http://groups.yahoo.com/group/rest-discuss/join
          > >
          > > (Yahoo! ID required)
          > >
          > >
          > >
          > > To change settings via email:
          > >
          > > mailto:rest-discuss-digest@yahoogroups.com
          > >
          > > mailto:rest-discuss-fullfeatured@yahoogroups.com
          > >
          > >
          > >
          > > To unsubscribe from this group, send an email to:
          > >
          > > rest-discuss-unsubscribe@yahoogroups.com
          > >
          > >
          > >
          > > Your use of Yahoo! Groups is subject to:
          > >
          > > http://docs.yahoo.com/info/terms/
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          >
          >

          --
          Bill Burke
          JBoss, a division of Red Hat
          http://bill.burkecentral.com
        • Bill Burke
          Whoops. I thought this was a different (Java) list. Sorry for the Java spin on this. I guess I should comment more generically then. I don t think an
          Message 4 of 6 , May 1, 2009
          • 0 Attachment
            Whoops. I thought this was a different (Java) list. Sorry for the Java
            spin on this.

            I guess I should comment more generically then. I don't think an
            Asynchronous web would:

            * break constraints. The constraints would be different. send/receive
            instead of put/post/get

            * break HATEOAS. In fact, IMO HATEOAS would thrive just as well in an
            asynchronous environment.

            Caching would seem to break, but you're not really doing read operations
            that are cachable in an asynchronous environment. For example, are
            emails cacheable?

            Bill Burke wrote:
            >
            >
            >
            > If "Asynchronous Web" means Servlet 3.0 and async request processing then:
            >
            > IMO, nothing should change for the client. It should be using the HTTP
            > APIs that come with the language/platform.
            >
            > It should be in some kind of while loop:
            >
            > while(true) {
            >
            > response = http.get() // probably post since we're consuming messages
            > doEvent(response)
            >
            > }
            >
            > The whole thing about HTTP is to save threads that are blocking. This
            > is the real performance benefit of async HTTP. Comet protocols tunnel
            > themselves through HTTP by taking advantage of keep alive semantics.
            > With these APIs, a client library is required and you're not really
            > using HTTP. You're only using it as a connection setup mechanism.
            > There are some small performance benefits to this. Once a connection is
            > set up, the server doesn't have to re-route incoming requests and can
            > just stream messages to the client.
            >
            > BTW, I have done some async HTTP abstractions:
            >
            > http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1.1-RC2/userguide/html/Asynchronous_HTTP_Request_Processing.html
            > <http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1.1-RC2/userguide/html/Asynchronous_HTTP_Request_Processing.html>
            >
            > amsmota@... <mailto:amsmota%40gmail.com> wrote:
            > >
            > >
            > >
            > > I have yet to read that paper (thanks for the link), but for now
            > > everything (not much) I found seems to treat some kind of "Asynchronous
            > > REST" as a extension of the simple request/response scheme, by allowing
            > > some kind of "deferred" response, or "notifications".
            > >
            > > I was thinking more in terms of push technology, in which a request can
            > > be started by the server instead of the client. What does that to our
            > > constraints?
            > >
            > > Client/server model -> breaks (in the sense that client/server being
            > > equivalent to request/response)
            > > Stateless protocols -> breaks? probably not
            > > Caching -> breaks?
            > > Uniform Interface -> doesn't necessarily break, but it could
            > > Layering -> doesn't necessarily break
            > > Optional Code-on-demand -> definitely doesn't break
            > >
            > > Identification of resources -> doesn't break
            > > Manipulation of resources through representations -> doesn't break,
            > > although the term "manipulation" here may not be the best
            > > Self-descriptive messages -> doesn't break ?
            > > Hypermedia as the engine of application state. -> it could break, and it
            > > probably will break
            > >
            > >
            > > However, if it break some of the constraints you can't call it REST, so
            > > basically the question will be: can REST be the architecture style of a
            > > Asynchronous Web application, or do we need a "revised" REST" or even a
            > > complete new style?
            > >
            > >
            > > On May 1, 2009 2:25am, mike amundsen <mamund@...
            > <mailto:mamund%40yahoo.com>> wrote:
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > Check out Rohit Khare's[1] "Asynchronous, Routed REST with Estimates
            > > and decentralized Decision functions (ARRESTED)[2]"
            > > >
            > > >
            > > > mca
            > > > http://amundsen.com/blog/ <http://amundsen.com/blog/>
            > > >
            > > > [1] - http://www.ics.uci.edu/~rohit/ <http://www.ics.uci.edu/~rohit/>
            > > > [2] - http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf
            > <http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf>
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > 2009/4/30 António Mota amsmota@... <mailto:amsmota%40gmail.com>>
            > > >
            > > > I was reading some articles about Asynchronous Web, and the question
            > > >
            > > > popped on my mind, what are the implications of Asynchronous Web on a
            > > >
            > > > REST-based architecture?
            > > >
            > > >
            > > >
            > > > And I mean that from the architectural point-of-view, not on
            > > >
            > > > implementations of asynchronous notifications from resources, or other
            > > >
            > > > similar implementation "tricks".
            > > >
            > > >
            > > >
            > > > What will be the implications on the architectural constraints and
            > > >
            > > > interface constraints of REST?
            > > >
            > > >
            > > >
            > > > Client/server model
            > > >
            > > > Stateless protocols
            > > >
            > > > Caching
            > > >
            > > > Uniform Interface
            > > >
            > > > Layering
            > > >
            > > > Optional Code-on-demand
            > > >
            > > >
            > > >
            > > > Identification of resources
            > > >
            > > > Manipulation of resources through representations
            > > >
            > > > Self-descriptive messages
            > > >
            > > > Hypermedia as the engine of application state.
            > > >
            > > >
            > > >
            > > > _______________________________________________
            > > >
            > > >
            > > >
            > > > Melhores cumprimentos / Beir beannacht / Best regards
            > > >
            > > >
            > > >
            > > > António Manuel dos Santos Mota
            > > >
            > > >
            > > >
            > > > _______________________________________________
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > ------------------------------------
            > > >
            > > >
            > > >
            > > > Yahoo! Groups Links
            > > >
            > > >
            > > >
            > > > To visit your group on the web, go to:
            > > >
            > > > http://groups.yahoo.com/group/rest-discuss/
            > <http://groups.yahoo.com/group/rest-discuss/>
            > > >
            > > >
            > > >
            > > > Your email settings:
            > > >
            > > > Individual Email | Traditional
            > > >
            > > >
            > > >
            > > > To change settings online go to:
            > > >
            > > > http://groups.yahoo.com/group/rest-discuss/join
            > <http://groups.yahoo.com/group/rest-discuss/join>
            > > >
            > > > (Yahoo! ID required)
            > > >
            > > >
            > > >
            > > > To change settings via email:
            > > >
            > > > mailto:rest-discuss-digest@yahoogroups.com
            > <mailto:rest-discuss-digest%40yahoogroups.com>
            > > >
            > > > mailto:rest-discuss-fullfeatured@yahoogroups.com
            > <mailto:rest-discuss-fullfeatured%40yahoogroups.com>
            > > >
            > > >
            > > >
            > > > To unsubscribe from this group, send an email to:
            > > >
            > > > rest-discuss-unsubscribe@yahoogroups.com
            > <mailto:rest-discuss-unsubscribe%40yahoogroups.com>
            > > >
            > > >
            > > >
            > > > Your use of Yahoo! Groups is subject to:
            > > >
            > > > http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > >
            > >
            >
            > --
            > Bill Burke
            > JBoss, a division of Red Hat
            > http://bill.burkecentral.com <http://bill.burkecentral.com>
            >
            >

            --
            Bill Burke
            JBoss, a division of Red Hat
            http://bill.burkecentral.com
          • António Mota
            ... If the constraints are different then it s not REST. It can be similar to REST, even be constructed following the methodology used by Mr. Fielding of
            Message 5 of 6 , May 2, 2009
            • 0 Attachment
              2009/5/1 Bill Burke <bburke@...>:
              > Whoops.  I thought this was a different (Java) list.  Sorry for the Java
              > spin on this.
              >
              > I guess I should comment more generically then.  I don't think an
              > Asynchronous web would:
              >
              > * break constraints.  The constraints would be different.  send/receive
              > instead of put/post/get

              If the constraints are different then it's not REST. It can be similar
              to REST, even be "constructed" following the methodology used by Mr.
              Fielding of applying successively sets of constraints to it. But it
              will not be REST.

              Let's look at the Client/Server style, for instance:

              "A server component, offering a set of services, listens for requests
              upon those services. A client component, desiring that a service be
              performed, sends a request to the server via a connector. The server
              either rejects or performs the request and sends a response back to
              the client. (...) A client is a triggering process; a server is a
              reactive process. Clients make requests that trigger reactions from
              servers. Thus, a client initiates activity at times of its choosing;
              it often then delays until its request has been serviced. On the other
              hand, a server waits for requests to be made and then reacts to them."

              This is clear *not* the case of a Asynchronous Web application. But then again,

              "Separation of concerns is the principle behind the client-server constraints."

              And "separation of concerns" should be a valid concern in such application...

              So, it's my interpretation of the client/server style not being
              applicable to a asynchronous app somehow wrong, or do we need another
              style that also implements "separation of concerns" using different
              constraints?

              And probably for the other sets of constraints, specially to the
              Uniform Interface constraints, similar considerations can be made?

              >
              > * break HATEOAS.  In fact, IMO HATEOAS would thrive just as well in an
              > asynchronous environment.
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.