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

19646Re: [rest-discuss] Reactive REST

Expand Messages
  • Michael Schuerig
    May 17, 2014
    • 0 Attachment
      On Saturday 17 May 2014 13:07:36 Erik Wilde dret@... [rest-
      discuss] wrote:
      > hello michael.
      > On 2014-05-17, 10:33, 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

      For the long story: http://www.reactivemanifesto.org/

      > > I've recently watched a presentation by Jafar Husain
      > >
      > > http://www.infoq.com/presentations/netflix-reactive-rest
      > >
      > > 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.
      > 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.

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


      Michael Schuerig
    • Show all 14 messages in this topic