Open Stack

On Wed, 7 Mar 2018, Hongbin Lu wrote:

> As a brief recap, we were discussing how Neutron API server should behave if invalid query parameters were inputted. Per my understanding, the general consensus is to make Neutron API server behave consistently with other OpenStack projects. The question for API-WG is if there is any guideline to clarify how OpenStack projects should handle invalid query parameters. Query parameters are various across different projects but it seems most projects support these four categories of query parameters: sorting, pagination, filtering, and fields selection. I saw API-WG provided a guideline to define how to handle valid parameters of these categories [2], but it doesn’t seem to define how to handle invalid parameters.
>
> I wonder if API-WG could clarify it. For example, if users provide an invalid filter on listing the resources, should the API server ignore the invalid filter and return a successful response? Or it should return an error response? Below is a list of specific scenarios and examples to consider:

It's hard to find, but there's existing guidance that touches on
this. From
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#failure-code-clarifications :

     [I]f the API supports query parameters and a request contains an
     unknown or unsupported parameter, the server should return a 400
     Bad Request response. Invalid values in the request URL should
     never be silently ignored, as the response may not match the
     client’s expectation. For example, consider the case where an
     API allows filtering on name by specifying ‘?name=foo’ in the
     query string, and in one such request there is a typo, such as
     ‘?nmae=foo’. If this error were silently ignored, the user would
     get back all resources instead of just the ones named ‘foo’,
     which would not be correct.  The error message that is returned
     should clearly indicate the problem so that the user could
     correct it and re-submit.

This same logic can be applied to invalid fields used in parameters
which can only accept a limited number of inputs (such as sort_key)
so in the examples you give a 400 would be the way to ensure that
the user agent is actually made aware that their request had issues.

I hope this helps. Please let the api-sig know if you think we
should adjust the guidelines to make this more explicit somehow.

-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent