Hi, On Jan 7, 2008 1:12 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 04.01.2008, 13:55 +0200 schrieb Jukka Zitting: > > Taking a different angle on this, we should better define what a > > "Resource" in Sling really is? We're claiming that Sling is "based on > > REST principles", which certainly suggests that Resources would be > > "RESTful". However, looking at the Resource interface now I have > > trouble making that association. Most specifically, the adaptTo() > > method is an anathema to the Uniform Interface principle in REST. > > In what respect is this method an anathema ?
The adaptTo() method is essentially a non-interface; it doesn't tell you anything about how to interact with a resource. There are no verbs! > I understand the adaptTo() method such, that this method allows to > get the resource in different presentations (to stay with the REST > terminology). As such, I certainly think, that this method perfectly > matches REST. I'd buy that argument if we only used the adaptTo() method like the HTTP GET method with an Accept header, i.e. to retrieve a representation of the resource state in a requested format, but instead the purpose of the method is to return something that you use to _interact_ with the resource. For example, a Servlet instance is certainly not a representation in the REST sense. In a REST architecture you use a defined set of actions (verbs) to interact with an identified resource, and representations are passed along as the parameters or return values of the actions. > What other roperties of the Resource interface makes you think, that we > might be violating the REST principles / architectural style ? For example, the Resource interface doesn't tell me how to modify the state of a resource. More fundamentally, the Resource interface defines no actions or verbs for a resource. There's nothing you can do with a Resource apart from retrieving it's metadata. You can use the adaptTo() method to adapt the resource to something else, but then you're no longer interacting with a Resource. > > Also I find the idea of an "iterable resource tree" to be at odds with > > REST principles. REST resources are accessed using identifiers and > > resource relationships are represented through links, not through an > > externally imposed tree structure. > > Maybe we can take a relaxed view on this. REST AFAIU does not prevent > enumerating resources, right ? So iterating the tree effectively is > taking a path P1 and finding all resources P2 such that P1 is a prefix > of P2 and the rest of P2 not being P1 is just a simple name. Sure, but that's something you can only do on the "server side", where you know how the resources are organized and related to each other. To expose such information to REST clients, you'd make the relationship information available as a collection of links embedded in a representation of a resource. You could certainly make the ResourceResolver understand such links, but if you implement such a feature directly (without going through resource representations) based on the underlying structure you introduce a tight coupling that breaks the Client-Server principle of REST. Of course there is no separate client or server within a Sling instance, so you could argue that the above doesn't apply. But then we really shouldn't be using the term "resource" at least in this context to avoid confusion with REST resources. BR, Jukka Zitting
