Having problems with message search?
I am addressing the security portion of your post. Hopefully this will give you some ideas.
<snip>
there are some elements that are modifiable or not depending on the privileges held by the (authenticated) user.
</snip>
First, I favor managing access rights using a combination of URI + HTTP_Method + Auth'ed_User. For example:
- user1 has GET,HEAD,OPTIONS for /collection/
- manager1 has GET,HEAD,OPTIONS,POST,PUT for /collection/
- admin1 has GET,HEAD,OPTIONS,POST,PUT,DELETE for /collection/
This means I focus on defining the proper Resources (addressed via URI) when I want to limit what state representations clients and server share.
In the case you provide, I would consider different Resources to handle different update privileges for the same stored data. This also clears up any attempts at doing partial updates (and therefore clears up caching issues) since none are needed now that there are different resources to handle the details.
In my example, the ability to pass different state representations is modeled as different resources. These various "secured" resource variations might still all "map" to the same data storage on the server, but that's not interesting to the client anyway since the data model is *not* the resource model on RESTful implementations.
mca
http://amundsen.com/blog/
http://amundsen.com/blog/
On Wed, Jul 1, 2009 at 15:42, Jim Edwards-Hewitt <jimeh@...> wrote:
Hi, everyone,
I'm a newbie here (though not to REST in general), and the list archives have been a great help in clarifying my understanding of a lot of REST concepts and suggesting good design elements. I have one part of my design right now where I'm unsure what a good RESTful approach would be.
I have resources that support GET and PUT, but contain some parts that clients are not allowed to modify. (This doesn't seem like an uncommon case; I would think that navigation links, for example, would typically not be modifiable in a PUT.) So is it better to:
1. Require clients to submit all the read-only parts unmodified in a PUT, and respond with an error code if they are absent or altered?
2. Take advantage of the leniency allowed in a server's implementation of PUT to ignore the read-only elements (or their absence)?
3. Separate read-only elements into a sub-resource that only supports GET? (This may not be feasible for resources which must be created as a whole.)
or something else?
Second, there are some elements that are modifiable or not depending on the privileges held by the (authenticated) user. I would think this would be expressed by a difference in the representation returned to the client, but what should that difference be? (My representations are XML documents, if there isn't a more general solution.)
And in a broader sense, I'd like the client to know which elements of the resource the user can modify, for presentation purposes. Is there a generally accepted way to do this, perhaps with form templates or XForms?
I'd be interested in any comments or alternative approaches, if I'm just looking at it from the wrong angle.
Thanks,
-- Jim
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rest-discuss/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/rest-discuss/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:rest-discuss-digest@yahoogroups.com
mailto:rest-discuss-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Offline 
Send Email
