I'll certainly admit to my thinking being influenced by past schema-driven projects.

I suppose I've also been thinking of GET/PUT formats being the same as a way of communicating the expected format to the client. (Though obviously that isn't the case when form-encoded input is accepted.) Is there any standard method or common convention for telling the client what media types and formats are accepted for a PUT request (other than forms)? The HTTP standard seems a bit thin on the subject of PUT media types, compared to GET.

  -- Jim

Subbu Allamaraju wrote:

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