Open Stack

I'm a proponent of checking the exact code. To me, its part of the API contract. From a practical point, it has also helped our automated tests catch bugs that nearly slipped by. One case I an remember is when some various POSTs started returning a 200 code as opposed to a 202, with the end result being that the requests responded to with a 200 actually were not processed. The only reason I could think of to generalize response code checking would be if it the response codes were ever vendor configurable.

Daryl

From: David Kranz
Sent: ‎January‎ ‎30‎, ‎2013 ‎4‎:‎08‎ ‎PM
To: openstack-qa at lists.openstack.org
Subject: [openstack-qa] Return codes for OpenStack APIs

There have been recent submissions to Tempest with code like:

self.assertTrue(resp['status'].startswith('2'))

It had been the consensus that we should be checking for actual status
codes. Some projects document the return
codes and others don't. This example was from a call to keystone to list
services and the result is not documented but the list tenants
calls says it could return 200 or 203. There should be a statement from
each project about whether it considers the return code to be part of
the spec.
Ideally this would be uniform across projects but it is not. Users of
the API really need to be able to know this. Any comments?

   -David

_______________________________________________
openstack-qa mailing list
openstack-qa at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20130130/97c9448a/attachment.html>