19647Re: [rest-discuss] Reactive REST
- May 17, 2014hello michael.
On 2014-05-17, 17:09, Michael Schuerig michael.lists@...
>>> The "reactive" buzzword has been conspicuously absent from thiswow. this seems to happily combine apples and oranges as well as bacon,
>>> 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
> For the long story: http://www.reactivemanifesto.org/
whiskey, and cup cakes. but it sure sounds like a good thing to have in
>> sounds like websockets (maybe not technically, but as the generali guess i am having trouble with looking at a connection as a resource
>> 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.
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:
>> not sure i agree that polling or long polling are the only (or best)these are two very different questions. they work very well in practice,
>> 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?
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.
erik wilde | mailto:dret@... - tel:+1-510-2061079 |
| UC Berkeley - School of Information (ISchool) |
| http://dret.net/netdret http://twitter.com/dret |
- << Previous post in topic Next post in topic >>