Bug 865861 - APIs to be introduced in 1.1 return incorrect status codes
APIs to be introduced in 1.1 return incorrect status codes
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
Unspecified Unspecified
high Severity low
: beta6
: ---
Assigned To: Jiri Stransky
pushpesh sharma
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2012-10-12 12:39 EDT by Jiri Stransky
Modified: 2014-08-04 18:31 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
API returned codes that did not conform to HTTP specifications. This update fixes the API to provide the correct return status codes.
Story Points: ---
Clone Of:
Last Closed: 2012-12-04 10:08:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jiri Stransky 2012-10-12 12:39:50 EDT
Description of problem:

APIs return codes that do not conform to HTTP spec. We shouldn't fix this for APIs introduced in 1.0 (to maintain compatibility), but we should fix this for APIs to be introduced in 1.1.

The APIs to be fixed are:

* providers

* provider accounts

* hardware profiles

* pools

* pool families

Providers and provider accounts APIs are present in 1.0 as well, but only index and show actions, so fixing create/update/delete actions for 1.1 should not break compatibility.

Actual results:

APIs return:

* 200 for creating a resource

* 200 for deleting a resource (the response body is then inconsistent across our APIs, some return the resource with <status>DELETED</status>, some return just <message>OK</message>)

* 400 for failed validations on create/update

Expected results:

* 201 for creating a resource

* 204 for deleting a resource (and response body should be empty)

* 422 for failed validations on create/update
Comment 2 Jiri Stransky 2012-10-12 13:01:35 EDT
Pull request submitted:

Prior to cherry picking the patchset into 1.1, we will have to cherry pick these two commits:


^^ these commits don't change application code, they just refactor/extend API-related Cucumber steps and RSpec expectations.
Comment 3 Jiri Stransky 2012-10-17 08:44:18 EDT
Pushed into upstream master as:

Comment 4 Jiri Stransky 2012-10-18 09:42:03 EDT
Cherry-picked into 1.1 as:

Comment 6 pushpesh sharma 2012-10-25 03:31:58 EDT
Few observations on the response for various API request:- 

1.) 201 for creating a resource
2.) 204 for deleting a resource and response body is empty
3.) 422 for failed validations on create
4.) 422 for failed validations on update
5.) 200 for update
6.) 200 for list/view resources 
7.) 500 for invalid delete request (ex:deleting default pool family) with error message like the following:-

<message>The default Cloud cannot be deleted.</message>

8.) 404 for delete/update of non-existing record/resource Id, with error message like the following:-

<message>Couldn't find PoolFamily with ID=1000</message>

Please provide Info if 5,6,7,8 has expected response codes and messages.
Comment 7 Jiri Stransky 2012-10-25 07:27:41 EDT
The correctness of status code for (7) would be discussable I guess, but it wasn't discussed and I believe we have no consensus on this so far, so doing anything about (7) isn't realistic for 1.1. The rest is correct.

So yes, the codes and messages are as expected.
Comment 8 pushpesh sharma 2012-10-25 09:58:13 EDT
Assuming Point 7 to be expected behaviour for now.Verifed response code for provider/provider_accounts pool/pool_family.
Comment 10 errata-xmlrpc 2012-12-04 10:08:40 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.