I agree with the inefficiency (it is an inconvenience, to be accurate)
part. That is why, there is no need to require clients to supply the
immutable parts. The "supply everything" requirement usually stems
from XML-schema driven applications, which is unnecessary.

Subbu

On Jul 6, 2009, at 10:28 AM, Sam Johnston wrote:

> On Sun, Jul 5, 2009 at 1:03 AM, Subbu Allamaraju <subbu@...>
> wrote:
>
>> 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.
>>
>
> The way I read the RFC is "*The PUT method requests that the
> enclosed entity
> be stored [as is] under the supplied Request-URI*", which is obvious
> for
> "simple" media types like images where anything else doesn't really
> make
> sense. While it does go on to talk about partial updates (mentioning
> the
> Content-Range header), PUTting a resource in its entirity knowing that
> immutable parts will be ignored and/or trigger errors seems neither
> efficient nor clean to me.
>
> Sam
>
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>