Dolph,
Ignore these arbitrary query string is what we did in keystone, current implementation did something deliberately to ignore them instead of passing them into the backend driver (If these parameter go to backend driver we will get nothing for sure), there might be no model answer for this situation, but I guess there must be some consideration at that time, do you still remember the concerns around this? Best Regards, Dave Chen From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: Wednesday, September 02, 2015 9:36 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering Does anyone have an example of an API outside of OpenStack that would return 400 in this situation (arbitrary query string parameters)? Based on my past experience, I'd expect them to be ignored, but I can't think of a reason why a 400 would be a bad idea (but I suspect there's some prior art / discussion out there). On Mon, Aug 31, 2015 at 10:53 AM, Ryan Brown <rybr...@redhat.com> wrote: On 08/27/2015 11:28 PM, Chen, Wei D wrote: > > I agree that return 400 is good idea, thus client user would know what > happened. > +1, I think a 400 is the sensible choice here. It'd be much more likely to help devs catch their errors . -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __________________________________________________________________________ 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
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ 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
