19656Re: [rest-discuss] Reactive REST
- May 23, 2014Hi Michael,I signed the reactive manifesto a while ago. I do think the RESTful applications need to be "reactive". To achieve that, I think a RESTful API should not only provide the data, but also afford how to manipulate the data when remote retrieval is expensive and not reliable. Query via path might be the most straightforward and safest way to that. Thinking about the model of html, we can hardly develop any modern web applications without the DOM. Furthermore, maybe sounding crazy, I also think a RESTful API without code-on-demand is a *dumb* API.I like what Jafar Husain showed about netflix's approach of jsong and effective pational caching control. Thanks for the link.Cheers,DongOn Sat, May 17, 2014 at 4:07 PM, Erik Wilde dret@... [rest-discuss] <firstname.lastname@example.org> wrote:
On 2014-05-17, 10:33, Michael Schuerig michael.lists@...[rest-discuss] wrote:haven't really seen it buzzing that much, but if you had to give it at
> The "reactive" buzzword has been conspicuously absent from this list.
> I'll try to fill this much needed gap.
least a little substance, how would you explain what it means? just
something that's driven by events rather than clients?sounds like websockets (maybe not technically, but as the general idea).
> I've recently watched a presentation by Jafar Husain
> where he describes something he calls "Reactive REST". I agree on the
> "reactive", however I have doubts about the "REST". In this particular
> case, all communication between a client and a server is over persistent
> connection to a single endpoint. If there's anything resembling
> resources, they are not identified by URIs. The persistent connection
> IMHO is a case of "conversational" state that REST is rather opposed to.
> No HATEOAS in sight.
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.not sure i agree that polling or long polling are the only (or best)
> What I'm pondering is whether an API can be RESTful and reactive at the
> same time or if is impossible as a matter of principle. AFAICT, a
> reactive API requires some way for the server to send events to the
> client. I don't think polling qualifies, which leaves a persistent
> connection. In effect, the server has to keep some amount of state for
> each session.
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.
it'll be interesting to see how this plays out in june at the w3c's web
of things workshop. clearly, in sensor scenarios, it would be very
convenient to have these kind of alerts, have them in a loosely coupled
and scalable way, and have them via protocols that are universally
supported. it may be the case that w3c will start working on something
in that space, but we'll know more after that workshop.
http://dret.net/netdret/publications#wil14a is a position paper that we
have submitted to this workshop. it may be the case that activity
streams take over as the new atom. we'll see about that, but they are
not all that different, and they use JSON, so all is good.
and in the same way as you can layer PuSH on atom to have a push model
on top of atom's data model, you can do the same for activity streams.
that might be the way open push protocols are going: you can poll for
activities, or you can subscribe to an activity hub that pushes to you
whatever you has subscribed to.
in my eyes, this could still be RESTful, only that of course you would
end up having more resources (such as subscriptions that need to be
managed and so on).
anyway, a very good question, a very interesting field, and with the
whole IoT/WoT movement now getting a serious hype push, maybe we'll get
to something open, useful, and RESTful in the next couple of years.just a question of cost. different protocols have different solutions
> Keeping session state has traditionally been regarded as a hindrance to
> scalability. Has technology advanced so much, eg with asynchronous,
> event-driven ("reactive") servers, that this is no longer a problem?
(PuSH subscriptions time out automatically, sMAP subscriptions never
time out), based on different scenarios. anything push-based is more
expensive than pure pull, because services/hubs need to keep track of
subscribers. but if the cost is smaller that the benefit, then this will
happen one way or another.web of things scenarios simply cannot work with long polling. if you
> Frankly, I'm lacking experience with systems where this kind of
> scalability would be required, so I'd happily use persistent
> connections, at least to begin with. Nonetheless, I'm interested in your
want to be connected to thousands of sensors in your building to figure
out when one is telling you that there is a fire, then you cannot have
open connections to all of them. the answer here is a layered
architecture, maybe some of it hidden as implementation details (sensors
just speaking MQTT to a hub), and other things exposed on the web level
(you being able to subscribe to that hub and get alerts). many solutions
have been built around this general pattern, but so far we lack a single
and coherent answer where to draw the boundary between the
implementation details and the open part, and what we should use for
that open part. as mentioned above, maybe that workshop will bring
together enough interested parties to start working on that issue.
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