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

Re: Re: [rest-discuss] Asynchronous Web and REST

Expand Messages
  • 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 1 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 2 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 3 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 4 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.