REST design - Validating non-numeric input, to a numeric field?

Question

Is there a general practice to validating REST requests, where the data is not the correct datatype? (Eg: submitting "bad value" to a int )

For example, if we have a "Shop item" entity, with mixed datatypes:

id: int
title: string
price: decimal
expiry: datetime

And we test the 'add' operation on the REST endpoint with a response with bad data:

{
    "title": "New item"
    "price": "bad value"
    "expiry": "Not a date"
}

Question: Is there a general practice to replying to requests with bad data?

Specifically - Do I need the error code/description to tell them that the field data is invalid? Would it be appropriate to just fall back to a 'mandatory field required' message? (Either scenario is going back as a HTTP 400)

Also, WebAPI / JSON.NET: Behind the scenes, I happen to be using Microsoft's WebAPI/JSON.Net. With the automatic deserialisation to an entity, correct data will map to their property/types just fine. I've also made all properties on the input models to be nullable, so we can validate for missing inputs. So bad data will be treated as a 'missing required field' validation.

Dropping back to making all properties a string, so we can further validate input seems a step backwards...

Answer 1

I don't know what the best practice is (REST leaves lots of room for interpretation and people chose to do it in different ways) but, personally, I would return a 400 Bad Request . If the request was invalid (eg invalid string value for a decimal or datetime field) or cannot be otherwise served because of some validation error then from my point of view it's a bad request.

Inside the response body I would then have a representation of an error that contains:

• the error code , something like 123 ;
• the error message something like Invalid value for field , Validation failed etc (maybe internationalized depending on the Accept-Language client header). This might be an array of field / message objects if you want to specifically tell where the issues are.

Also, I would not make all the entity properties a string (it defeats the purpose of having an entity to bind to in the first place) and would not make them all nullable to validate for missing values (I would do the opposite and use [Required] ).

I'm not very familiar with Microsoft's WebAPI but you should be able to intervene in the validation process. For application validations you rely on ModelState.IsValid to return a HttpStatusCode.BadRequest while for plain invalid data you customize the parameter binding maybe with some HTTP message handler of some sort.

Answer 2

Take a look at http://soabits.blogspot.dk/2013/05/error-handling-considerations-and-best.html which goes into details about good error handling in APIs. You can also search StackOverflow for "error handling [rest]" which gives a good set of results.

Answer 3

This is how we handle it in our API:

{
  "code": 422,
  "errors": [
    {
      "field": "title",
      "message": "can't be blank"
    },
    {
      "field": "price",
      "message": "must be greater than 0"
    },
    {
      "field": "expiry",
      "message": "wrong date format"
    }
  ],
  "message": "Validation failed"
}

The format of the error messages stays the same for any type of errors. What can change is the error Array (it might be empty) and the root message.