Representations in a request (e.g. PUT or POST) and representations in
a response (e.g. GET or a PUT) need not be absolutely the same. HTTP
servers are not databases that blindly store the data. Using PUT to
update the mutable parts of a resource is perfectly okay. At least, I
don't see anything that breaks HTTP.

Subbu


On Jul 2, 2009, at 8:01 AM, Sam Johnston wrote:

>
>
> Jim,
>
> Typically you would express the overall writeability of a resource
> via OPTIONS (e.g. if you can only GET it's read only), but if you've
> got, say, a template driven website and you only want the body to be
> updated then that's something different.
>
> I would almost certainly NOT be using PUT for this, rather accepting
> POSTs of just the midifiable data (perhaps in HTML forms or some XML-
> based format). If you were to use XML then a GET (with the
> appropriate Accept: header) could return just the parts which are
> modifiable by the client. Optionally you could add information to
> the URL about whether the client wants just the writeable elements
> or the whole lot, or even markup the elements as writable (or not).
>
> Hope that helps,
>
> Sam
>
>
> On Wed, Jul 1, 2009 at 9:42 PM, 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
>
>
>
>
>