REST as a general architectural model?

[Geuis Teses]

Since I'm not as up to speed on the low-level system requirements
(stdio, file system, etc) as a lot of other folks here, take this with
a couple grains of salt and some tequila.

Does it make any sense for a standardize module or interface system to
be built around the REST model? Off the top of my head, it kind of
makes sense that you could build file, stdio, database access, etc on
REST principles. People can then plug in whatever technologies they
want, whether it be Mysql or Couchdb, Rhino or v8.

[Peter Svensson]

I would very much like this. perhaps like this; Even if there exists other, more effective ways of communicating data, having a RESTive interface to that sweet spot automatically would be a great boon.

Cheers,
PS

[Breton]

In this respect, I really like the way helma handles REST style
architecture (Though I think it could be pushed further).

URL's in helma are automatically mapped to an object graph in your
program. 1:1, url:object, it's very tidy. For more dynamic sections
of an application, you can override an object's "getChildElement"
function, to return an object based on the suburl.

For instance

example.com/pages/1/ would return the first page....but

PageManager.js:

function getChildElement (name) {
return this.pageByUrlsafeName[name]
}

and then you can do
example.com/pages/rest-and-javascript/

then once an object is resolved to resemble what might traditionally
be viewed as a "directory", the "files" are mapped to methods on that
object

Page.js:

function main_action () {
this.renderSkin("main");
}

function edit_action_get () {
this.renderSkin("edit")
}

function edit_action_post () {
this.title = req.postParams.title;
this.renderSkin("edit");
}


and so on, making the urls
example.com/pages/rest-and-javascript/
and
example.com/pages/rest-and-javascript/edit

and mapping different behavior to GET and POST actions of that url.


I think helma could go further in making this object graph a bit more
dynamic. As it stands, one must construct the object graph
declaritively, using a series of folders, .js source files, and
type.properties files which define the relationships between the
different objects (which are actually host objects).

What would be really cool is if a whole section of a website could be
generated dynamically out of a function. Or perhaps a whole website
built by specifying a few input parameters in one end, out comes a
website on the other- write the source files to disc and tweak to
perfection.

On Jan 31, 6:39 am, Peter Svensson <psvens...@gmail.com> wrote:
> I would very much like this. perhaps like this; Even if there exists other,
> more effective ways of communicating data, having a RESTive interface to
> that sweet spot automatically would be a great boon.
>
> Cheers,
> PS
>

[Breton]

Oh of course the great benefit of having REST all the way down is
CACHING. Template render? Cached. Database result? Cached. Well, just
those two things would make the thing perform much better than your
standard PHP app out of the gate. Helma is proof of that.

[Mario Valente]

Breton wrote:
> In this respect, I really like the way helma handles REST style
> architecture (Though I think it could be pushed further).
>
> URL's in helma are automatically mapped to an object graph in your
> program. 1:1, url:object, it's very tidy. For more dynamic sections
> of an application, you can override an object's "getChildElement"
> function, to return an object based on the suburl.
>
> For instance
>
> example.com/pages/1/ would return the first page....but
>

Basically the Zope way :-)

Now what I want (would like) is that when I call
example.com/people/Mario through the web I dont get
an HTML page: I get a JSON doc. Maybe I could get
an HTML page by calling example.com/people/Mario/view
Or that page would be viewable at a standard page
at example.com/view/people which would then call the
individual person URLS, receive the JSON data and map
to the fields on the page.

-- MV

[Kris Zyp]

And this is exactly what Persevere does as well, exposing JS objects
through a REST/HTTP interface and caching data from the DB in JavaScript
objects, using the REST paradigm throughout. And you are absolutely
correct, this does have huge performance benefits. The model is
completely dynamic as well, you can create new tables, objects,
properties, schemas on the fly (I think you were lamenting the static
nature of Helma).

This is an interesting topic, but isn't this much higher level that the
focus of the group in implementing low-level APIs? There has been a lot
of good discussion of RESTful approach to JSON (i.e. JS structured data)
at the restful-json google group.

Kris

[Peter Svensson]

We can still work on several levels at once. The core task is to provide low-level APIs to the world. Secondary (and a continuing endeavor) is to see what parts of existing inventions (for that is what they are) are comfortable synchronizing their specs into a standard of some sort.

Some will and some won't, but the base is key.

Cheers,
PS

[Kevin Dangoor]

On Fri, Jan 30, 2009 at 4:02 PM, Kris Zyp <kri...@gmail.com> wrote:
> This is an interesting topic, but isn't this much higher level that the
> focus of the group in implementing low-level APIs? There has been a lot
> of good discussion of RESTful approach to JSON (i.e. JS structured data)
> at the restful-json google group.

I think that any SSJS topic is fair game for discussion here. It's
entirely possible that someone will have a really cool high-level idea
that influences the lower level APIs that become standardized.

Kevin

[Breton]

of course HTTP has a facility for this: the accept header. It probably
would be wisest to use the accept header rather than blanket serving
JSON to any GET request. if a client requests text/html in its accept
header as a first preference, that's what it should get. But likewise
if it's got json at the top, the system ought to allow for that.

I think the suggestion in the other thread has merit: Make as many
apis have a uniform "REST-like" interface as possible, for maximum
polymorphism. Our server module takes any object with an abstract
"resource collection" interface, and serves it as a website. Meanwhile
our file module, xml module, JSON module, and SQL module, and template
module can produce objects with that interface. At another meanwhile,
our caching module can accept a "resource collection" object at one
end, and return another one at the other end, whilst caching the
interactions inbetween: Basically a proxy object for this uniform
interface. This would let us also cache anything with this "resource
collection" interface.

[chbm]

On Jan 30, 8:44 pm, Mario Valente <mfvale...@gmail.com> wrote:

>    Or that page would be viewable at a standard page
>   at example.com/view/people which would then call the
>   individual person URLS, receive the JSON data and map
>   to the fields on the page.
>
>    -- MV

One of the design goals of my CSJS templating engine is allowing
static html template pages which are then rendered CS using a JSON
object. So for /people/Mario the browser would get /people/view.html
which in turn would load /people/Mario.json.

[Bertrand Delacretaz]

On Jan 30, 9:32 pm, Breton <zenpsy...@gmail.com> wrote:
> ...URL's in helma are automatically mapped to an object graph in your
> program. 1:1, url:object, it's very tidy....

Sling [0] does a similar thing, but mapping to JCR Nodes instead of
objects:

Sling stores data in a JCR repository, which is basically a
(potentially large) tree of Nodes and Properties attached to those
Nodes, adressable by paths like in a filesystem.

URL maps to a Resource, which is usually a Node in the JCR repository.
That mapping is 1:1 at the path level. Plus extension and "selectors":
a path like /content/foo.print.a4.html points to the /content/foo
Node, print.a4 are selectors and html is the extension.

The Resource then defines a "resource type", usually via a Property on
the Node. If our /content/foo Node has a sling:resourceType Property
with value "bar", Sling looks for scripts under /apps/bar to process
the request. For the html extension, for example, /apps/bar/html.js is
used, if it exists. That could also be /apps/bar/html.rb for a Ruby
script, if that scripting engine is installed.

This gives you RESTful interactions with content, with no
configurations or annotations - just drop a script under the right
path.

-- Bertrand Delacretaz
-- http://grep.codeconsult.ch

[0] http://incubator.apache.org/sling