How should a RESTful service expose read-only properties on mutable resources?

Viewed 11501

I am working on designing a resource for this service which has a set of mutable properties and a set of immutable ones (for example, status which is generated by the service and not something the client may change).

I need to include this in responses to GET requests for the resource but am not sure what to do if someone then sends the resource with a PUT request.

Forcing the caller to know which properties are immutable feels wrong, but silently discarding updates also feels incorrect. Responding with the updated resource to the PUT request might solve the issue, but it's imperfect since the caller shouldn't have to do a diff of its request and the service's response to find out if a property was accepted.

Any thoughts on the right way forward?

P.S. I looked at How should I update a REST resource? but it's different from this question and promotes an overly-chatty API design.

4 Answers

Another solution is to send the read-only fields back as HTTP headers. That way you can keep the GET and PUT resources identical.

This probably makes most sense if the read-only fields are primarily "technical" fields such as createTime, updateTime, etc. Status could be regarded as a technical field as well ?

Related