19649Re: [rest-discuss] Reactive REST
- May 18, 2014Hi Michael,I don't quite follow why you think a permanent HTTP session is against RESTful principles. Isn't the HTTP session management at a different level (transport) than the actual resource management and the stateless principles associated to it?In the same vein, would you also consider one cannot define a RESTful service over persistent HTTPS connections for instance?Best,HubertOn May 18, 2014, at 8:02 AM, Michael Schuerig michael.lists@... [rest-discuss] <email@example.com> wrote:
On Saturday 17 May 2014 18:15:13 Erik Wilde dret@... [rest-
> 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).
No, a connection isn't a resource. But keeping a connection open from
each client to the server puts a strain on the server. Ideally, a
RESTful service is loaded only "dynamically" in the sense that the
("static") number of clients is irrelevant, what counts is the
("dynamic") number of requests per unit of time. My understanding of
REST is that this is deliberate and very helpful for scalability. Open
connections are a strain on a service even in the absence of any
requests. For one thing, a single server can only manage a limited
number of open connections at a time.
In REST, at least as far as I understand it(!), state is only supposed
to figure as transferred resource state; session state is prohibited.
My understanding may be wrong and I'm perfectly willing to tone down the
RESTful ideal for practical purposes. The point I'm trying to make is
purely a matter of classification, ie that I think persistent
connections are not RESTful.
> 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.
So, is "reverse REST" still RESTful? Yes, the individual push request
from server to client probably qualifies. The architecture as a whole
probably doesn't. As you write, state needs to be maintained which
A truly RESTful solution would have to do without such state. *I* don't
see how that is possible, but that's why I started this discussion.
Also, I'd like to repeat that I don't mean not being RESTful, or not
being reactive, as some kind of condemnation. Both approaches offer very
sensible advice in general, I'm interested in seeing how well they fit
> >> 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).
OK, I take these as existence proofs that push works in practice.
> 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.
Right now I'm not trying to do anything, I'm first and foremost trying
to understand the landscape. As a consequence, my specific questions
keep changing. My starting point was the question "What would a
'reactive' and RESTful web application look like from browser through
app server to database". Especially when it comes to the communication
see how to reconcile statelessness and event-drivenness.
- << Previous post in topic Next post in topic >>