-1

When you have an endpoint that can take a set of valid parameters, how do you do validation on a non-empty set of elements?

Say you have a request /api/endpoint?my_list=1,2,3 where 1, 2, 3 are the only valid values for my_list. What do you do when the following request is made: /api/endpoint?my_list=1,3,7?

Should you filter out the invalid values and process my_list=1,3 or return an error? What do you do if all elements are invalid?

Kyle McVay
  • 1,897
  • 1
  • 11
  • 14
David Grossman
  • 11
  • Is this a request to do three operations, or a request to do one operation with/on a collection of data? – Telastyn Apr 17 '19 at 21:34
  • The latter: A request to do one operation on a collection of data. For example, we might want to filter out values of `my_list` that aren't specified. – David Grossman Apr 17 '19 at 21:44
  • Let's start with how this should work for a single element in the list, as in: `?my_list=7`. What should this do if `7` doesn't exit -- does it make sense to offer an inquiry response, or, should this be an error? – Erik Eidt Apr 17 '19 at 22:58
  • See also the comment in an [answer](https://softwareengineering.stackexchange.com/a/329684/63202), to a question: "It is impossible to make multiple requests in a single HTTP request. On the other hand, it is perfectly possible to make a single HTTP request which says "perform the following actions, and let me know what the results are". – Erik Eidt Apr 17 '19 at 22:59

2 Answers2

3

It depends.

If the collection represents a series of independent operations passed together to cut down on chatter, then it can make sense to return a collection of results. Some passed, some didn't.

If the collection represents a series of transactional operations passed together to imply "please do all of these things" then you should treat them as a proper transaction - either they all succeed or they all fail.

If the collection represents a set of inputs, then it usually is useful to discard "bad" inputs. This helps prevent people from flooding your service with bogus requests. It also allows you to treat "non-existent" inputs the same as "invalid access" inputs so that you're not leaking data to people without permission to operate on certain inputs. A bunch of invalid inputs is the same as an empty set of inputs, which reduces complexity of error handling.

If the collection represents a cohesive bundle of data, then modifying that bundle is often not a good idea since you're silently changing its meaning. In those cases it's usually better to return a nice single error about the invalid input (unless it's a permissions or existence issue, in which case you want it to look like a nice single error about normal invalid input).

Telastyn
  • 108,850
  • 29
  • 239
  • 365
0

You should return a 404 (maybe a 400)

At the end of the day a URI is just an identifier for a resource, including the search param bits. If the server cannot find the resource you requested it should simply return a 404.

You could return a 400 because you know that 7 is not valid and thus the URI can never represent a resource (a 404 is for a resource that doesn't exist but could in the future, ie something where there is nothing wrong with the URI it just isn't a resource the server can find)

I would be careful using 400 for something like a 7 in a list of ids though if it is entirely possible that 7 will at some point be a valid param.

When in doubt go with 404

Cormac Mulhall
  • 5,032
  • 2
  • 19
  • 19
  • I would actually think a [422 response](https://httpstatuses.com/422) is appropriate: "The server understands the content type of the request entity (hence a 415 Unsupported Media Type status code is inappropriate), and the syntax of the request entity is correct (thus a 400 Bad Request status code is inappropriate) but was unable to process the contained instructions." – Greg Burghardt Apr 19 '19 at 11:47
  • 422 is sort of ok. Technically the response is part of the WebDAV spec and relates to the content body rather than the URI. But I've definitely seen it used as a general "you have a semantic rather than syntactic error" response in the wild – Cormac Mulhall Apr 19 '19 at 14:15