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

19653Re: [rest-discuss] Reactive REST

Expand Messages
  • Erik Wilde
    May 20, 2014
    • 0 Attachment
      hello michael.

      On 2014-05-18, 8:02 , Michael Schuerig michael.lists@...
      [rest-discuss] wrote:
      > On Saturday 17 May 2014 18:15:13 Erik Wilde dret@... [rest-
      > 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.

      HTTP has persistent connections and that's perfectly fine. because it's
      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 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
      > hinders scalability.

      it just makes things more expensive, and depending on what you're trying
      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't
      > see how that is possible, but that's why I started this discussion.

      http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons might
      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 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
      > together.

      it's a good question and one that probably will become increasingly
      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
      the scenario.

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


    • Show all 14 messages in this topic