5266Re: [rest-discuss] REST requires HTTP or other transports
- Oct 7, 2005On Oct 7, 2005, at 5:48 AM, Jeoff Wilks wrote:
> The difference in verbs illustrates the push vs. pull difference. InSo would I if that was what I wrote, but it isn't. Dissertations
> 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.
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.
You might want to look at Rohit's dissertation for more exploration.
> "The interaction method of sending representations of resources toUnregulated push models are infeasible on the Web. There needs 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) -
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 mostI think the key thing that people should learn from my dissertation
> sense. Yet the pull model shows cracks when used for real-time
> delivery scenarios like RSS.
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 RESTEr, or they could just contract with Akamai and they would never
> (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
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.
Roy T. Fielding <http://roy.gbiv.com/>
Chief Scientist, Day Software <http://www.day.com/>
- << Previous post in topic Next post in topic >>