So where in REST is the MVC?

Still trying to get my head around REST. Looking at sling, I do see two different approaches:

• view/model combined: a resource is represented by a markup (html), which contains both view and model information. The controller (browser) is responsible for the correct representation and the hypermedia functionality (hyperlinks, forms), which allows navigation and manipulation of the represented data
  
• model exclusively: the resource is represented by a data structure (json), which is both rendered to the controllers (browser) taste as view

Now, from a design point of view, the second one seems cleaner, and very compatible with the MVC pattern. But the first approach is the one the web is build upon, soooo there has to be something about it ...

The idea spinning around in my head is to implement the first approach with Griffon and Sling: Sling will deliver SwingBuilder fragments which then will be interpreted by Griffon. Stay tuned...

Flex/Flash wasn't made for REST

Well, it did take longer than others, but I finally got the message: Flash was not built with HTTP in mind. There are other issues flying around, but I think it all boils down to HTTP not being treated as first-class-citizen in the Flex/Flash environment.

I guess that the reason is a historical one: all remote connection protocols where proprietary, only in the last years Adobe opened itself a little bit (by releasing BlazeDS and open sourcing Flex). Now I think Adobe should go 2 steps further:

1. implement standards (e.g. using HTTP how it was meant to be used)
2. open source the whole stack

This is highly speculative, but perhaps the "Nay" to EcmaScript4 was due to the apparent closeness of the Flash ecosystem.

The saddest thing is that Flex is great! Real good default (looks nice out of the box), a real component model, just plain fun! Next stop: Dojo, I think ...

RESTful Authorization Model Considerations

Considering the fact that URIs map to resources in a RESTful design, an authorization model almost automatically means a URI authorization model:

• URIs are subject to authorization decisions
  
• URIs offer a hierarchical authorization scheme
  
• additionally, the limited list of allowed actions (verbs) leads way to a simple definition of ACLs (Access Control List), more or less the same as for file systems (read,write etc etc)

All in all this design is quite a non-event since it all fits together quite obviously.

One thing to consider is the old question of attribute based security decisions. A real world example is a blog where the author first checks the comments before publishing them. The attribute would be whether the comment already has been reviewed or not.

There are 2 possibilities to do do the authorization check in a declarative manner:

1. either the ACL is attached directly to the resource
   
2. or the resources (posts to be reviewed) are stored in another place of the URL hierarchy, e.g. '/comments/review' instead of '/comments'. The ACL would be attached to the directory instead of the resource itself (directory being a resource in its on right)
   

Both make use of ACL which looks something like this:

ACL(resource):

• reviewer:read/write/delete (this allows to move)
• author: read/write

Both possibilities have got their respective advantages. The second one seems to be easier, but has an impact on the hierarchy of resources. Is it allowed to define a resource hierarchy according to a cross-cutting concern like security?