[rest-practices] Read-only fields in a representation type

[Mark McLoughlin]

On Fri, 2010-04-23 at 11:51 -0400, Bob McWhirter wrote:
> >> Rather than silently discard read-only fields, though, I'd prefer  
> >> us to
> >> return an error. That way the semantics are clear.
> >
> > That's kinda the opposite of what we expect from clients - for  
> > those, we
> > want them to pick out what they know about, and ignore the rest. As  
> > long
> > as what they send is unambiguous, I don't see the harm in ignoring
> > read-only fields.
> 
> In fact, one usage is to fetch XML, simply modify that document (using  
> xpath) and returning it, in its entirety, back to the server.

Yeah, that's got to be a common case.

> There, I'd hope that server really only considers fields that've  
> honestly *changed*.  If I replace a readonly value with another  
> different value, I'd expect an error (Sorry, can't modify a read-only  
> field), but otherwise, I'd expect it to notice what really got changed  
> in the read/write attributes.

I like it, except for read-only fields that change a lot - e.g. the
amount of free space on a disk.

> With REST, client and server are exchanging their views of the world.   
> The client's not instructing the server to change particular fields.  
> More "Hey, I now consider this object to look like this".
> 
> That can either be compatible, or incompatible (ie, changes to read- 
> only fields) with the server's policy.

Right - default policy should be to ignore changes to read-only fields,
but where we think the client is expressing a view that is completely
incompatible with our view, then we should return an error - e.g. if the
client tries to change the UUID of a VM

Cheers,
Mark.