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

    [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
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to