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.

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