Bob La Quey wrote:
Not really. Caching only works well etc. REST is not just caching.
Sure. But it's one of the points, and the only real point that applies
to stock prices.
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.
Of course. But that's because HTTP has all kinds of headers and such to
tell you how long it lasts. Without an Expires header, caching stuff
like this isn't a good idea.
I really do not understand your lament.
Why do you need a URI to do it? What does the URI give you that a simple
indirect function call doesn't?
Stateless service design is a major reason the Web scales to a global
information application.
"""
Nonsense. There are huge numbers of highly stateful web sites like Amazon
that scale just fine. The network with the most state in it is also the
biggest and busiest (the PSTS). What makes the web scale to a global
information application is the huge piles of money that's thrown at it.
There are much better ways of getting scaling, like the store-and-forward
semantics of email. If you discount all the sites that actually, you know,
have state, like Amazon, Facebook, GMail, etc, then sure, you can dispatch
any request to any server.
Session is state. I will grant you that. But it is one state per
session. Roughly equivalent to spawning one server per session. Not
that big a problem.
Sure. But ... how is using a URI better than using a function call. One
object per session? I don't see the advantage of being able to
dynamically map connections at runtime arbitrarily.
"active:generateConfig"
Very RESTful, that. NOT! Especially when the micro-kernel starts caching
the results, eliminating the value of having the configuration actively
generated.
Same inputs = same outputs so the second time through you cache. This
really not that hard to understand.
Right. But the whole point of generating the configuration on each call
is that you *don't* get the same outputs on the same inputs here. The
point is that the sqlServer:yadda URL maps to an active:generateConfig
URL to dynamically select the server on each SQL call. (Maybe you didn't
read that bit recently enough to know what they're talking about.)
for instance suppose I need to calculate y = sin(x).
Suppose you need to calculate y = rand().
A hash of the arguments points to the output. If null then calculate.
This is not difficult. It simply falls out as a natural consequence
functional programing of which REST is an example.
Yes. And my point is that they then go and mix in active:generateConfig,
which is specifically *not* functional, and claim it's an advantage of
their REST system.
The request carries such stuff ... you tell me though. What is needed?
Not sure. Maybe check out the Microsoft Singularity papers on it. They
have an interesting system for their loosely-coupled mechanisms.
Basically, amongst other interesting features, the receiver of the
request decides whether the program that authenticated the user is
sufficient for that program's tastes.
I actually think that while not RESTful, the Singularity work does a much
better job of decoupling than this stuff does.
I do know nothing of Singularity. I will have to explore it.
It's pretty cool. They have a couple of white papers, but if you
download the actual distribution, there's a directory full of research
papers in the distribution.
You are seeing problems I do not. I am using this type of thing with a
simple urls.py file to map urls to python functions in complex
websites (See Django.) I find the approach works well and is quite
simple both to implement and to understand. Clearly, YMMV.
Sure. That doesn't make it restful. That just makes it use URIs. You can
easily have REST apps without URIs and URIs without REST.
There are a number of ways to make things loosely coupled. REST is one,
that
only works well if your problem fits into that sort of domain. Almost
none
of the systems I've seen actually implement REST properly.
I would like to see some other good examples.
Good examples of what, specifically?
Of "a number of ways to make things loosely coupled." which is a
direct quote from your statement, eh?
Data driven programming. Extra indirections in your code. All kinds of
"object design patterns" like Observer and Factory. DLLs.
SMTP. UNIX pipes.
Concurrency-Oriented Programming (COP), like Erlang or Hermes, where you
can change out the running code while it's running without breaking the
connections other components have to it.
Half the research in computer science language design is figuring out
how to make things more loosely coupled.
REST includes a whole bunch more than just "loose coupling with URIs."
Using URIs for everything (or even textual strings naming everything,
which seems closer to what they're doing in the ROC paper) has an
overhead that (in spite of caching) would seem to be higher than you'd
want for most things.
SSL I will grant you. You are not going to cache SSL. A session cookie
effectively creates a personal server after which REST works just
fine.
Um, no. You seem to think that REST is "URIs and HTTP" or something.
It's not. If there's a "personal server" holding your state, that's
exactly what doesn't scale. "Representative State Transfer" means the
representation of the state is transfered to the client on each request.
If the server stores the state, it isn't REST.
I mean, in the URL that you posted, step one of describing REST is "it's
client/server."
Step two of describing REST, and I quote, is
"We next add a constraint to the client-server interaction:
communication must be stateless in nature, [...] such that each request
from client to server must contain all of the information necessary to
understand the request, and cannot take advantage of any stored context
on the server". If you have a cookie that's storing a session ID,
you're storing state on the server. (If you have a cookie that's storing
the entire shopping cart, of course, that's different.)
The third step is "Cache constraints require that the data within a
response to a request be implicitly or explicitly labeled as cacheable
or non-cacheable." Sure, but I don't see how their microkernel helps.
Why would caching the answer at the microkernel level help more than
caching the answer at the SQL server level?
The very next section says "The REST interface is designed to be
efficient for large-grain hypermedia data transfer, optimizing for the
common case of the Web, but resulting in an interface that is not
optimal for other forms of architectural interaction." Which is kind of
what I'm saying. Why would I want to convert my SQL query (which may be
compiled) into a string I need to compile again for the next query,
re-optimize it, run it again, turn the result into XML, and then turn
the XML back into the structure I wanted in the first place, by passing
around strings to other processes which will build the binary blob I
want in the first place? In what way can that possibly be considered
efficient, especially if I'm looking up the whole configuration and
reestablishing the connection to the server every query? If I can
already pass around binary blobs, why do I want to turn a parameterized
SQL query into a text string, nest that inside another text string with
appropriate quoting, and then unnest it and unquote it when it gets
where it's going?
The ability to change which database instance the web server talks to on
the fly isn't really a difficult problem to solve requiring an entirely
new OS microkernel. Neither is converting a SQL table to XML or XML to a
Java instance.
I am not a REST fundamentalist, "There is no God but REST," but you
are not making much of a case against RESTful styles.
I'm not arguing against REST. I'm arguing that REST as a fundamental
principle of OS design is certainly at least unintuitive and, in my
offhand opinion, kind of silly. REST is an excellent principle when it
works. REST is an awful principle to adhere to when it isn't appropriate.
You seem to be confusing REST with caching among other things. Caching
!= REST though REST often enhances caching.
It's number two, after number one being "don't have sessions." :-)
According the the very URL you posted, yet. ;-) Indeed, the ROC paper
you posted claims that caching cures the overhead associated with using
REST for everything to start with.
--
Darren New / San Diego, CA, USA (PST)
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
