(I posted this reply privately instead of publicly, so I'm re-posting.)

Ah, that does make it more clear. So I might have two (or more) different
resources/URIs for one behind-the-scenes object, each of which contains only the
elements that the user can modify, which supports GET/HEAD/OPTIONS/PUT?

I like that; it seems much cleaner than the direction I was going.

I think I'd also want to have a resource which contains all the elements and
supports only GET/HEAD/OPTIONS (since, in my case, they're all readable if the
user is authorized to see the resource at all), but I think I'd want it to have
an edit link to navigate to the appropriate read/write resource. Does that mean
that in order to avoid trouble with caching, I'd have to have parallel versions
of that resource with different URIs as well, since the edit link would be
different depending on the user?

-- Jim

--- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
>
> Jim:
> 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/
>
>
>
> 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
> >
> >