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

19647Re: [rest-discuss] Reactive REST

Expand Messages
  • Erik Wilde
    May 17, 2014
    • 0 Attachment
      hello michael.

      On 2014-05-17, 17:09, Michael Schuerig michael.lists@...
      [rest-discuss] wrote:
      >>> The "reactive" buzzword has been conspicuously absent from this
      >>> list.
      >>> I'll try to fill this much needed gap.
      >> haven't really seen it buzzing that much, but if you had to give it at
      >> least a little substance, how would you explain what it means? just
      >> something that's driven by events rather than clients?
      > In the context of RESTful APIs, the interesting (tricky) part appears to
      > be is how to make things event-driven. I take this to imply that
      > communication over a channel is in general one-way. Clients send events
      > to servers (without a reply payload), clients receive events from
      > servers.
      > For the long story: http://www.reactivemanifesto.org/

      wow. this seems to happily combine apples and oranges as well as bacon,
      whiskey, and cup cakes. but it sure sounds like a good thing to have in
      the end.

      >> sounds like websockets (maybe not technically, but as the general
      >> idea). to me, REST is on a different level than this plumbing. in the
      >> same way as you can do REST and notREST over HTTP, the same probably
      >> applies to any of the alternative interaction styles. as you point
      >> out, REST has more (and more abstract) constraints than just the
      >> protocol that's used.
      > I'm not convinced that REST is on a different level. The reason is that
      > I think that a persistent connection between client and server counts as
      > state that has to be managed by the server for each session. I'm not
      > saying that this is bad by itself, it just seems to me not to be in
      > keeping with REST tenets. Which, in turn, wouldn't necessarily be a
      > problem, either. I'm not interested in passing judgment, but rather in
      > understanding how the commandments of REST and reactive interact.

      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). to me, what changes
      may be a sensor's state, and the question is how to get that information
      to consumers. whether you do it by pulling or pushing really does not
      change the fact that after doing one or the other, the changed resource
      state will be available on the consumer side. it's just that pulling it
      has vastly different characteristics in terms of scaling, which is why
      the web scales so nicely.

      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.

      if you're interested to read a bit more, here's a starting point:

      http://dret.net/netdret/publications#pau11b

      >> not sure i agree that polling or long polling are the only (or best)
      >> alternatives. there's quite of stuff to be done in the area that i
      >> often refer to as "reverse REST": clients subscribe, and then there's
      >> 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). 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.

      cheers,

      dret.

      --
      erik wilde | mailto:dret@... - tel:+1-510-2061079 |
      | UC Berkeley - School of Information (ISchool) |
      | http://dret.net/netdret http://twitter.com/dret |
    • Show all 14 messages in this topic