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

5266Re: [rest-discuss] REST requires HTTP or other transports

Expand Messages
  • Roy T. Fielding
    Oct 7, 2005
    • 0 Attachment
      On Oct 7, 2005, at 5:48 AM, Jeoff Wilks wrote:

      > The difference in verbs illustrates the push vs. pull difference. In
      > fact, Fielding argues in his dissertation that push-vs-pull is the key
      > difference. He also states that a push model can not scale to web
      > levels, though I question this assertion.

      So would I if that was what I wrote, but it isn't. Dissertations
      are a successful walk through a minefield -- summarizing them
      is not. One of the professors who signed my dissertation,
      David S. Rosenblum, was working at the time on Internet-scale
      event-based notification systems.

      <http://www.ics.uci.edu/~irus/wisen/index-old.html>

      You might want to look at Rohit's dissertation for more exploration.
      <http://www.ics.uci.edu/~rohit/>

      > "The interaction method of sending representations of resources to
      > consuming components has some parallels with event-based integration
      > (EBI) styles. The key difference is that EBI styles are push-based.
      > The component containing the state (equivalent to an origin server in
      > REST) issues an event whenever the state changes, whether or not any
      > component is actually interested in or listening for such an event. In
      > the REST style, consuming components usually pull representations.
      > Although this is less efficient when viewed as a single client wishing
      > to monitor a single resource, the scale of the Web makes an
      > unregulated push model infeasible."
      >  -5.4 (paragraph 4) -
      > http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

      Unregulated push models are infeasible on the Web. There needs to
      be something regulating the flow of events, which means aggregations
      and source-based filtering. I did not even attempt to address that
      topic because it wasn't *my* topic.

      > For reference/archive data, a pull model definitely makes the most
      > sense. Yet the pull model shows cracks when used for real-time
      > delivery scenarios like RSS.

      I think the key thing that people should learn from my dissertation
      is that principled design means thinking about the problem you want
      to solve first, within the context you need to solve it, and then
      selectively applying constraints to get the properties you want.
      REST was just one example of that method. A natural "next step"
      would be to look at a different problem (say, ISENs) and see what
      additional constraints could be added to EBI in order to make it
      more scalable. I would not start with REST as the basis.

      > It seems to me that you could take all the other benefits of REST
      > (standardized wire protocol, URIs, distributed caching, limited verb
      > set) and apply it to a push model (perhaps over XMPP) and see the end
      > of problems like this:
      >
      >   "...InfoWorld.com now sees a massive surge of RSS newsreader
      > activity at the top of every hour, presumably because most people
      > configure their newsreaders to wake up at that time to pull their
      > feeds. If I didn't know how RSS worked, I would think we were being
      > slammed by a bunch of zombies sitting on compromised home PCs."
      >  - http://www.infoworld.com/article/04/07/16/29OPconnection_1.html

      Er, or they could just contract with Akamai and they would never
      see any "massive surge". *shrug*

      Push models suffer from a major social problem: those that gain the
      most are the least likely to pay for it. For example, every news
      service thinks that they are the center of the universe. Consider
      what would happen if every blog client received an event whenever
      a story was published that the news service *thinks* is worthy of
      their immediate attention. We already know what happens: SPAM.
      To solve the scalability problem you will first need to regulate
      that social problem, because publishers will not self-regulate.

      It is, however, one heck of a dissertation topic.

      Cheers,

      Roy T. Fielding <http://roy.gbiv.com/>
      Chief Scientist, Day Software <http://www.day.com/>
    • Show all 14 messages in this topic