Having problems with message search?
Well, the “[as is]” isn’t
actually part of the RFC. The body of the PUT request is simply a *representation* of the state. Consider a
resource that could produce alternative representations for GET, say via
content negotiation. I could do a PUT with an Atom representation and then still
GET a JSON representation afterward. So I don’t see that PUT requires you
to literally store the exact message body (although, as you mention, that’s
entirely allowable).
In AtomPub [1], for example, this is one
reason why a successful PUT returns a 200 OK where the body contains the
resulting representation—then the server can apply the PUT to the
portions it needs, and the client can see the result.
If you like, however, if the server sees
that the client has modified an unmodifiable portion of the entity (e.g. some
piece of computed metadata, like a last-updated timestamp), the server can
reply with a 409 Conflict with additional detail [2].
Jon
[1] http://bitworking.org/projects/atom/rfc5023.html#rfc.section.5.4.2
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10
……..
Jon Moore
Comcast Interactive Media
From:
rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of Sam Johnston
Sent: Monday, July 06, 2009 1:29
PM
To: Subbu Allamaraju
Cc: Jim Edwards-Hewitt;
rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss]
Resources with read-only and read-write parts
On Sun,
Jul 5, 2009 at 1:03 AM, Subbu Allamaraju <subbu@subbu.
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@surety.com >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
Offline 
Send Email