Bug 865861 - APIs to be introduced in 1.1 return incorrect status codes
APIs to be introduced in 1.1 return incorrect status codes
Status: CLOSED ERRATA
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.1.0
Unspecified Unspecified
high Severity low
: beta6
: ---
Assigned To: Jiri Stransky
pushpesh sharma
: Triaged
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2012-12-04 10:08:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:
https://github.com/aeolusproject/conductor/pull/120


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

f967b6af3978eb13500568d327b193013bc21190
44129254286c0037895651ad923a1b59b7192ff6

^^ 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:

39a01794e6658ac4314148e7b428dbb15b3a5d45
63b12cc8a9193102561c6680c7956f832427c3d0
e5c24ccd416f2139f6e3604613a6db39197666ce
1902f31a55797e88ecdb511da506537f5946967b
Comment 4 Jiri Stransky 2012-10-18 09:42:03 EDT
Cherry-picked into 1.1 as:

6a01ecf0d4fb5f345f33992c6ccbd6349824fb42
567be21bddb474a96c199330070fcbb82e8ab9f9
1ddc0320d85708fcec503400d730c787ae9cbc83
eec058d2c76bfa135b1e10eb13723840a661a032
04279437b6f9367261c462c685cc47e8bafe9bc5
c1bfa9484102fbdf2d1993b2379c2fa3dc0b1b83
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:-

<error>
<code>Error</code>
<message>The default Cloud cannot be deleted.</message>
</error> 

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

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


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.

http://rhn.redhat.com/errata/RHEA-2012-1516.html

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