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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
