Should a ReST API silently ignore request to change nonexistent field?

Question

Consider a ReST API which provides an interface to a database.

Should a the server respond with an HTTP 400 Bad Request on a PUT or PATCH request which attempts to specify a new value for a column which does not exist in the database? Should the server silently ignore the error? Should the server do something else which I have not mentioned here?

Answer 1

Do not silently ignore the request
I'm not sure how you could anyway, besides the server closing the connection without sending a response.

400 is good, as is 409. You may also want to consider 403 Forbidden: The server understood your request but is refusing to fulfill it.

400 is typically for mal-formed requests.
403 is good for when the request was sufficiently well-formed that your server code was able to parse it and understand what the request was for. I think that most closely meets your requirement here.

However, a line in your question worries me:

attempts to specify a new value for a column which does not exist in the database

Requests should not be modifying values of columns in a database. They should be modifying the content of a resource. The two are not the same. It is easy to fall into the trap of thinking "oh, lets just expose this domain object as an HTTP resource" but that can cause scalability problems down the line. In general, you should have more resources in your URI space than model objects. This allows you to cache the fairly static parts of your model with a different policy than those much more dynamic parts.

For example, in an order processing system, the delivery address changes very infrequently, but the progress tracker might change every few minutes. Give the two data different URIs and different cache policies.

Answer 2

Silently ignoring errors is a recipe for making your API difficult to work with. Unless you provide extremely good documentation (and sometimes even then) the developer that is working on a client for your API is unlikely to know that parts of their request may be ignored. Consequently they are likely to become confused as to why the resource does not reflect what they last PUT. Wasting peoples time like this is not likely to make your API popular.