Question

I’m designing a RESTful API that currently has resources that include some elements that can be updated by clients and others that can’t. As an example:

{
    id : "1234",
    firstName  : "George",
    lastName   : "Burdell",

    blogPosts : { href : "http://server.com/user/1234/blogposts"}
}

A client of the API can PUT a new resource or PATCH an existing resource, but in the example they could only write to firstName and lastName. id and blogPosts are generated by the server and are not modifiable by the client.

What’s the recommended way to handle an attempt to write to a non-writable field? Return 401 and ignore the entire update document? Is 401 the appropriate response?

Is having a resource that includes both writable and non-writable elements a bad idea? (I’m new at this, but it seems that it may often be unavoidable, especially in cases like the example when linked to related resources).

Answer 1

Return a 403 and don’t update the resource.

403 Forbidden

The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If
the request method was not HEAD and the server wishes to make public
why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the entity. If the server does not wish to make
this information available to the client, the status code 404 (Not
Found) can be used instead.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html