19653Re: [rest-discuss] Reactive REST
- May 20, 2014hello michael.
On 2014-05-18, 8:02 , Michael Schuerig michael.lists@...
> On Saturday 17 May 2014 18:15:13 Erik Wilde dret@... [rest-HTTP has persistent connections and that's perfectly fine. because it's
> discuss] wrote:
> 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.
orthogonal to the *interactions*. what would be bad would be if the
persistent connection established some context that was necessary for
the individual interactions. what is not a problem at all is to keep the
TCP connection open and have multiple HTTP interactions across it,
because that saves networking resources, and reusing the TCP connection
is just an optimization.
how connections are managed really is not so much a concern for the
HTTP/REST perspective. it just has to be done in a way that system
design does not depend on established session state.
>> but it is entirely possible to envisage that HTTP pull is like UPSit just makes things more expensive, and depending on what you're trying
>> 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
> hinders scalability.
to achieve, you might be willing to pay this cost, or not. introducing
subscribers as resources certainly changes the picture and affects
scalability quite a bit, but that does not mean that the resulting
design is not RESTful anymore. as long as interactions are
resource-oriented and stateless, and resource representations are using
hypermedia, all is well.
> A truly RESTful solution would have to do without such state. *I* don'thttp://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons might
> see how that is possible, but that's why I started this discussion.
be interesting to read, and looks at similar issues. but it also makes
some assumptions, such as that the service compiling this "here is what
changed" list access to this information somehow.
> Also, I'd like to repeat that I don't mean not being RESTful, or notit's a good question and one that probably will become increasingly
> being reactive, as some kind of condemnation. Both approaches offer very
> sensible advice in general, I'm interested in seeing how well they fit
important, the more real-time information sources (such as sensors) we
have, and the more we have apps that want to consume this information.
personally, i don't think there's an easy answer here, it all depends on
for example, on http://tiledfeeds.yimingliu.com/ we propose an
architecture where we aggregate resources spatially, and then build a
(pull-oriented) delivery architecture on top of that. that works well if
and only if your resources are spatially distributed. and if you feel
like it, you could still PuSH-enable those tiled feeds, but then you'd
run into the "subscriber management cost" issue mentioned above.
if you don't want/need push, you can simply start reading
http://geofeeds.org/earthquakes/02301021.xml, refresh your copy
occasionally, and you'll get all the information about major earthquakes
in california (which right now will never change, because this is a
static demo and not connected to a live feed of earthquake data).
- << Previous post in topic Next post in topic >>