On Wed, Oct 1, 2008 at 8:07 PM, Bob La Quey <[EMAIL PROTECTED]> wrote: > On Wed, Oct 1, 2008 at 6:33 PM, Darren New <[EMAIL PROTECTED]> wrote: >> Bob La Quey wrote: >>> >>> A good example of a RESTish approach is NetKernel. See http://1060.org/ >> >> Just going thru the whitepaper at >> http://www.1060research.com/resources/docs/ROCForDevelopers.pdf >> by the time they get to page six, they're making incorrect assertions about >> how great their stuff is. It's good to know that they, for example, can >> aggressively cache the result of an SQL select call, even though the data in >> the actual database has changed. > > Not all of the data has changed. Selective smart caching is not > necessarily that difficult. > >>It's also good to know that because they're >> using XML, they're not "brittle" with respect to the types of data they >> return. Let them change <symbol> to a URI and watch stuff break. > > He, he ... not a bad point. > >> REST really only works well when you have data that isn't changing, expiring >> frequently, and etc. > > Not really. Caching only works well etc. REST is not just caching. > >>What's the URI for "IBM's current stock price"? > > how about > > http://www.ibm.com/current_stock_price/ > > There is absolutely no reason why that URI cannot return the current > stock price. We do this kind of mapping all the time in Django. I can > probably write the code to do that in about 15 minutes. Using any of a > number of Python web frameworks it would require little more than > mapping that url to a function that looked up the current IBM price > and returned an HTML page with the price embedded in it. > > I really do not understand your lament.
OK. Maybe this is what is bothering you. How can one URI return multiple responses? The answer is that URI != request. A request carries other data besides the URI. For instance, a request can carry Date data. See http://www.faqs.org/rfcs/rfc2616.html 4.5 General Header Fields There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These header fields apply only to the message being transmitted. general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.18 | Pragma ; Section 14.32 | Trailer ; Section 14.40 | Transfer-Encoding ; Section 14.41 | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 RFC 2616, HTTP 1.1 13.2.3 Age Calculations In order to know if a cached entry is fresh, a cache needs to know if its age exceeds its freshness lifetime. We discuss how to calculate the latter in section 13.2.4; this section describes how to calculate the age of a response or cache entry. In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially hosts running origin servers and caches, SHOULD use NTP [28] or some similar protocol to synchronize their clocks to a globally accurate time standard. OK, that's a wrap as far as I am concerned. BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
