- May 17, 2014The "reactive" buzzword has been conspicuously absent from this list.
I'll try to fill this much needed gap.
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.
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
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?
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
- Next post in topic >>