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.

Answer 3

It depends on your documentation.. how strict you want to be ..
But commonly speaking, Just ignore it. Most other servers also ignore request parameters it didn't understand.

Example taken from my previous post

Extra Query parameters in the REST API Url

"""Google ignore my two extra parameters here https://www.google.com/#q=search+for+something&invalid=param&more=stuff"""

Answer 4

Imagine I have the following JSON schema:

{
   "frequency": "YEARLY",
   "date": 23,
   "month": "MAY",
}

The frequency attribute accepts "WEEKLY", "MONTHLY" and "YEARLY" value. The expected payload for "WEEKLY" frequency value is:

{
   "frequency": "WEEKLY",
   "day": "MONDAY",
}

And the expected payload for "MONTHLY" frequency value is:

{
   "frequency": "MONTHLY",
   "date": 23,
}

Give the above JSON schema, typically I will have need a POJO containing frequency, day, date, and month fields for deserialization.

If the received payload is:

{
   "frequency": "MONTHLY",
   "day": "MONDAY",
   "date": 23,
   "year": 2018
}

I will throw an error on "day" attribute because I will never know the intention of the sender:

1. frequency: "WEEKLY" and day: "MONDAY" (incorrect frequency value entered), or
2. frequency: "MONTHLY" and date: 23

For the "year" attribute, I don't really have choice. Even if I wish to throw an error for that attribute, I may not be able to. It's ignored by the JSON serialization/deserialization library as my POJO has no such attribute. And this is the behavior of GSON and it makes sense given the design decision.

Navigating the Json tree or the target Type Tree while deserializing

When you are deserializing a Json string into an object of desired type, you can either navigate the tree of the input, or the type tree of the desired type. Gson uses the latter approach of navigating the type of the target object. This keeps you in tight control of instantiating only the type of objects that you are expecting (essentially validating the input against the expected "schema"). By doing this, you also ignore any extra fields that the Json input has but were not expected.

As part of Gson, we wrote a general purpose ObjectNavigator that can take any object and navigate through its fields calling a visitor of your choice.

Extracted from GSON Design Document

Answer 5

Just ignore them.

Do not give the user any chance to reverse engineer your RESTful API through your error messages.

Give the developers the neatest, clearest, most comprehensive documentation and parse only parameters your API need and support.

Answer 6

I will suggest that you ignore the extra parameters. Reusing API is a game changer in the integration world. What if the same API can be used by other integration but with slightly extra parameters?

Application A expecting:

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

Application B expecting:

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

Simple get application application A to ignore "color" will do the job rather to have 2 different API to handle that.