RESTful API - Correct behaviour when spurious/not requested parameters are passed in the request

Question

We are developing a RESTful api that accepts query parameters in the request in the form of JSON encoded data.

We were wondering what is the correct behaviour when non requested/not expected parameters are passed along with the required ones.

For example, we may require that a PUT request on a given endpoint have to provide exactly two values respectively for the keys name and surname:

{     "name": "Jeff",     "surname": "Atwood" } 

What if a spurious key is passed too, like color in the example below?

{     "name": "Jeff",     "surname": "Atwood",      "color": "red" } 

The value for color is not expected, neither documented.

Should we ignore it or reject the request with a BAD_REQUEST 400 status error?

We can assert that the request is bad because it doesn't conform to the documentation. And probably the API user should be warned about it (She passed the value, she'll expects something for that.)

But we can assert too that the request can be accepted because, as the required parameters are all provided, it can be fulfilled.

Answer 1

Having used RESTful APIs from numerous vendors over the years, let me give you a "users" perspective.

A lot of times documentation is simply bad or out of date. Maybe a parameter name changed, maybe you enforce exact casing on the property names, maybe you have used the wrong font in your documentation and have an I which looks exactly like an l - yes, those are different letters.

Do not ignore it. Instead, send an error message back stating the property name with an easy to understand message. For example "Unknown property name: color".

This one little thing will go a long ways towards limiting support requests around consumption of your API.

If you simply ignore the parameters then a dev might think that valid values are being passed in while cussing your API because obviously the API is not working right.

If you throw a generic error message then you'll have dev's pulling their hair out trying to figure out what's going on and flooding your forum, this site or your phone will calls asking why your servers don't work. (I recently went through this problem with a vendor that just didn't understand that a 404 message was not a valid response to an incorrect parameter and that the documentation should reflect the actual parameter names used...)

Now, by the same token I would expect you to also give a good error message when a required parameter is missing. For example "Required property: Name is missing".

---

Essentially you want to be as helpful as possible so the consumers of your API can be as self sufficient as possible. As you can tell I wholeheartedly disagree with a "gracious" vs "stern" breakdown. The more "gracious" you are, the more likely the consumers of your API are going to run into issues where they think they are doing the right thing but are getting unexpected behaviors out of your API. You can't think of all possible ways people are going to screw up so enforcing a strict adherence with relevant error messages will help out tremendously.

Answer 2

If you do an API design you can follow two path: "stern" or "gracious".

• Stern means: If you do anything I didn't expect I will be mad at you.
• Gracious means: If I know what you want and can fulfil it I will do it.

REST allows for a wonderful gracious API design and I would try to follow this path as long as possible and expect the same of my clients. If my API evolves I might have to add additional parameters in my responses that are only relevant for specific clients. If my clients are gracious to me they will be able to handle this. Having said that I want to add that there is a place for stern API design. If you are designing in an sensitive domain (e.g. cash transactions) and you don't want to leave room for any misunderstanding between the client and server. Imagine the following POST request (valid for your /account/{no}/transaction/ API):

{ amount: "-100", currency : "USD" } 

What would you do with the following (invalid API request)?

{ amount: "100", currency : "USD", type : "withdrawal" } 

If you just ignore the "type" attribute, you will deposit 100 USD instead of withdrawing them. In such a domain I would follow a stern approach and show no grace whatsoever.

Be gracious if you can, be stern if you must.

Update:

I totally agree with @Chris Lively's answer that the user should be informed. I disagree that it should always be an error case even the message is non-ambiguous for the referenced resource. Doing it otherwise will hinder reuse of resource representations and require repackaging of semantically identical information.