Hey Jim,

On Tue, Jul 7, 2009 at 3:34 AM, Jim Edwards-Hewitt<jimeh@...> wrote:
> Ah. That makes a lot of sense, but I don't think I've seen it expressed that
> way before. Are there content-type definitions that make that explicit? (I
> suppose it mostly applies to xml or html-based formats, where the same type
> of language is used to express the state of the resource and the purely
> content-type elements.)

A form (POST) that accepts only the values that represent the state of
the resource is one way to make it explicit (sigh... if only I could
say method="PUT" path="/foo" in the form tag)

Sandeep Shetty
http://sandeep.shetty.in/


> --- In rest-discuss@yahoogroups.com, Sandeep Shetty <sandeep.shetty@...>
> wrote:
>>
>> Hey Jim,
>>
>> On Thu, Jul 2, 2009 at 1:12 AM, Jim Edwards-Hewitt<jimeh@...> wrote:
>> > 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.)
>>
>> IMO, you seem to be confusing between the state of the resource and
>> its representation. GET and PUT allow you to retrieve and set the
>> state of the resource. The data format used for transferring that
>> state is the media type. "Navigation links" are specific to the media
>> type and not the state of the resource. I could PUT
>> application/atom+xml or application/x-www-form-urlencoded and GET
>> text/html.