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

19649Re: [rest-discuss] Reactive REST

Expand Messages
  • Hubert A Le Van Gong
    May 18, 2014
    • 0 Attachment
      Hi Michael,

      I don't quite follow why you think a permanent HTTP session is against RESTful principles. Isn't the HTTP session management at a different level (transport) than the actual resource management and the stateless principles associated to it?
      In the same vein, would you also consider one cannot define a RESTful service over persistent HTTPS connections for instance?


      On May 18, 2014, at 8:02 AM, Michael Schuerig michael.lists@... [rest-discuss] <rest-discuss@yahoogroups.com> wrote:

      On Saturday 17 May 2014 18:15:13 Erik Wilde dret@... [rest-
      discuss] wrote:

      > i guess i am having trouble with looking at a connection as a resource
      > with state (unless you talk about network monitoring and management
      > scenarios, which are an entirely different beast).

      No, a connection isn't a resource. But keeping a connection open from 
      each client to the server puts a strain on the server. Ideally, a 
      RESTful service is loaded only "dynamically" in the sense that the 
      ("static") number of clients is irrelevant, what counts is the 
      ("dynamic") number of requests per unit of time. My understanding of 
      REST is that this is deliberate and very helpful for scalability. Open 
      connections are a strain on a service even in the absence of any 
      requests. For one thing, a single server can only manage a limited 
      number of open connections at a time.

      In REST, at least as far as I understand it(!), state is only supposed 
      to figure as transferred resource state; session state is prohibited.

      My understanding may be wrong and I'm perfectly willing to tone down the 
      RESTful ideal for practical purposes. The point I'm trying to make is 
      purely a matter of classification, ie that I think persistent 
      connections are not RESTful.

      > but it is entirely possible to envisage that HTTP pull is like UPS
      > ground and free, whereas there may be UPS overnight which costs a bit
      > but is faster. if you do that, you get to specify your identifier, and
      > then (and this is why i call this "reverse REST") you become the
      > resource to be pushed to, i.e. your resource needs to be known by the
      > event source. there are tons of PubSub approaches out there, only
      > that coming up with one that works robustly and in a scalable at web
      > scale so far hasn't worked. the main reason is that for pull, sources
      > don't need to know the consumers, whereas for push that state needs
      > to be maintained, which is expensive.

      So, is "reverse REST" still RESTful? Yes, the individual push request 
      from server to client probably qualifies. The architecture as a whole 
      probably doesn't. As you write, state needs to be maintained which 
      hinders scalability.

      A truly RESTful solution would have to do without such state. *I* don't 
      see how that is possible, but that's why I started this discussion.

      Also, I'd like to repeat that I don't mean not being RESTful, or not 
      being reactive, as some kind of condemnation. Both approaches offer very 
      sensible advice in general, I'm interested in seeing how well they fit 

      > >> a push model. there are a variety of push protocols (PuSH, MQTT,
      > >> APN,
      > >> C2DM, sMAP) out there, but none so far has taken over the world.
      > > 
      > > I don't know anything about these models/protocols. Do they work in
      > > practice at this time? In particular, if the client is a single-page
      > > application running in a browser?
      > these are two very different questions. they work very well in
      > practice, for example across all iOS devices (APN), across all
      > android devices (C2DM), in building automation scenarios (sMAP), or
      > in large sensor network settings (MQTT). 

      OK, I take these as existence proofs that push works in practice.

      > they all come with different
      > design goals and constraints, and it seems that you have something
      > specific in mind as well. as long as you don't better understand the
      > specific constraints of the scenario you have in mind, picking a
      > solution (or writing down the requirements for a new one) probably
      > will be hard.

      Right now I'm not trying to do anything, I'm first and foremost trying 
      to understand the landscape. As a consequence, my specific questions 
      keep changing. My starting point was the question "What would a 
      'reactive' and RESTful web application look like from browser through 
      app server to database". Especially when it comes to the communication 
      between browser (or rather JavaScript-client) and app server, I don't 
      see how to reconcile statelessness and event-drivenness.


      Michael Schuerig

    • Show all 14 messages in this topic