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

19650Re: [rest-discuss] Reactive REST

Expand Messages
  • Philippe Marsteau
    May 19, 2014
    • 0 Attachment
      FWIW, HTTP is an APPLICATION (transfer) protocol and not a TRANPORT protocol. TCP is the transport protocol HTTP uses.

      I think the benefits of REST architectural style over Pub/Sub style is the scalability associated to not require servers to keep tracks of clients. The statelessness constraint means a 2nd calls of a client shouldn't/mustn't assume something on the server following a previous call, like an HTTP (application) session could be used for on the server). Because of the assessment, you can literally swap one machine with another (or use true load balancing solutions w/o sharing or distributing caches) without any impacts for the clients open "sessions" (from a client perspective). To achieve this, any input that a second call needs following a first call should be transferred to client after each call (state is transfered to client instead of kept on server).

      This being said you certainly can model a pub/sub polling scenario within REST constraints. The pushing scenario however do require state on the server that belongs to client. Because the client determines lifecycle of these "push config" dynamic resources, eg when to delete it, that data need to be kept in sync between machines, and handling* that extra state breaks statelessness of REST (*handling like in auto-expiring subscriptions over time, etc.)

      The other technical pb of pub/sub over HTTP are firewalls or related network issues. It is not uncommon that clients have firewalls in place that let outgoing calls but require IP whitelisting to let calls come in. That further reduces scalability of such model (basically each client must be seen as a server and vice-versa). The clients costs is typically higher than server (clients establish the HTTP connection and close them as appropriate for their use cases). This cost is acceptable because you usually have many clients for one server. If the server had to pay that connection cost (eg to push data), it would be central and all clients would deal with a less responsive server as a result.

      Finally, pub/sub model implies a level of trusts normal HTTP app servers do not need to have. Blindly connecting to any HTTP endpoint opens to security vulnerabilities. The client (subscriber) will typically expect some shared secret or key cert exchange, and the server may not be willing to blindly post data to unknown locations.

      Hope this helps. Interesting discussion. Pub/sub scenarios clearly exist and are adapted for some use cases, but I don't thing HTTP transfer protocol is adapted. BTW, Roy's dissertation did mention Pub/Sub (as well as others) style before describing REST style; refer to it to compare the constraints with one another, and why he believed REST style was better suited for scalability.

      ---
      Phil
      On May 19, 2014 at 2:55:29 AM EDT, Hubert A Le Van Gong hubertlvg@... [rest-discuss] <rest-discuss@yahoogroups.com> wrote:
       

      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?


      Best,
      Hubert


      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 
      together.

      [...]
      > >> 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

      -- 
      Michael Schuerig
      mailto:michael@...
      http://www.schuerig.de/michael/


    • Show all 14 messages in this topic