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. 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.
REST really only works well when you have data that isn't changing,
expiring frequently, and etc. What's the URI for "IBM's current stock
price"?
"""
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.
"active:generateConfig"
Very RESTful, that. NOT! Especially when the micro-kernel starts
caching the results, eliminating the value of having the configuration
actively generated.
"active:[EMAIL PROTECTED]@ffcpl:/pictures/boxes.png"
I'm not sure that's even a valid URL, or that if it is the scheme is
going to be "active".
"""
The gate keeper can then examine the request and its context for
security credentials ...
"""
Would be nice if they talked about what kind of security credentials you
have, given that everything's identified by a URI.
I actually think that while not RESTful, the Singularity work does a
much better job of decoupling than this stuff does. I would think any
big program where all the layers are linked by untyped strings is going
to be awful to maintain. That's just a guess, tho. I mean, how would you
even look at a program and figure out what URIs it might ask for? How do
you manage all these baroque rewrite rules, just to talk to the database
full of state?
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?
For example, any web site with a custom login page isn't REST. Amazon's
cloud stuff isn't REST. They're all RESTish, but fail in the details that
give you the benefits of REST.
I understand the login point as follows: sessions break REST.
Yes. The same request can't go to a different server with the same data
and work.
The Amazon stuff fails because altho there aren't sessions, it encodes
the user identification in the data (the login problem) and doesn't
actually give you URLs inside the results. If you don't know what parts
of the XML actually describe URLs and which don't, you can't parse the
result.
CouchDB is about as close to an actual REST service I've seen.
Is that your point?
One point of REST is to allow caching in the network and such. If you
have a login page, you aren't caching stuff. SSL breaks REST. Cookies
break REST. Most everything people use to do actual applications breaks
REST.
--
Darren New / San Diego, CA, USA (PST)
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
