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

Question

Consider the ReST API, which provides an interface to the database.

If the server responds with an HTTP 400 Bad Request response to a PUT or PATCH request, which tries to specify a new value for a column that does not exist in the database? Should the server silently ignore the error? Should the server do something else that I didn’t mention here?

Answer 1

Ignore the request silently
I'm not sure how you could, anyway, except for the server closing the connection without sending a response.

400 is good, as is 409. You might also want to consider 403 Forbidden: the server understood your request, but refuses to fulfill it.

400, as a rule, for incorrectly formed requests.
403 is good when the request was well-formed enough that your server code was able to parse it and understand what the request was for. I think that most closely matches your requirement here.

However, the line in your question bothers me:

trying to specify a new value for a column that does not exist in the database

Queries must not change the values ​​of columns in the database. They must modify the contents of the resource. These two options do not match. It's easy to fall into the trap of thinking "oh, just show this domain object as an HTTP resource", but this can lead to scalability issues in the string. In general, you should have more resources in the URI space than model objects. This allows you to cache fairly static portions of your model with different policies than those that are more dynamic.

For example, in an order processing system, the delivery address changes very rarely, but the progress tracker can change every few minutes. Specify two different URIs and different caching policies.

Answer 2

Silently ignoring errors is a recipe that makes it difficult to work with the API. Unless you provide very good documentation (and sometimes even then), a developer working with a client for your API is unlikely to know that parts of their request may be ignored. Therefore, they may be confused as to why the resource does not reflect the fact that they are the last PUT. Spend time like these people is unlikely to make your API popular.

Answer 3

If the client can resend without an additional value, you should answer 409. from spec :

10.4.10 409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user will be able to resolve the conflict and resubmit the request. The response body MUST include enough information for the user to know the source of the conflict. Ideally, the response object will contain sufficient information for the user or user agent to resolve the problem; however, this may not be possible or required.

Conflicts most often occur in response to a PUT request. For example, if version control was used, and the PUT object included changes to a resource that contradicts a previously (third-party) request, the server can use the 409 response to indicate that it cannot fulfill the request. In this case, it will probably contain a list of differences between the two versions in the format defined by the Content-Type response.

Answer 4

In my experience, you should not silently ignore additional properties and consider PUT / POST as if they were not there. Consider how a consumer calls an API with additional properties in a model. If the consumer of the API has a typo in the name of an optional property, the API will respond to 200, and the consumer will take significantly longer debugging time than if 400 were returned. Often, the most disappointing mistakes come from innocent typos such as laed rather than lead.