The most complicated resource of this type is an Administrator account. The
current representation is:

<admin>
<uid>{id}</uid>
<status>{status string}</status>
<roles>
<role>{role-name}</role>
...
</roles>
<vcard>...</vcard>
<link rel="http://...#organization" href={org URL} title="{org name}" />
</admin>

The user may be an ordinary user or a privileged user (leaving aside users with
read-only access, since that case is easy.) An ordinary user can modify the
contact information in the vcard structure, a privileged user can modify the
roles and status (active/disabled/etc.), and the uid is immutable.

(As a further complication, a privileged user can only add or remove roles that
their own account possesses.)

I'm already thinking that my roles may be better expressed as a set of
<role-name> tags with true/false values rather by the presence/absence of a
<role> tag as in the structure above, to avoid ambiguity on PUTs.

-- Jim

--- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...>
wrote:
>
> Hi Jim,
>
> can you provide an example representation for the mutable/immutable
> use case?
>
> Jan
>
> On Jul 1, 2009, at 3:42 PM, Jim Edwards-Hewitt 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
> >
> >
> >
>