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
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.
Pushed into upstream master as: 39a01794e6658ac4314148e7b428dbb15b3a5d45 63b12cc8a9193102561c6680c7956f832427c3d0 e5c24ccd416f2139f6e3604613a6db39197666ce 1902f31a55797e88ecdb511da506537f5946967b
Cherry-picked into 1.1 as: 6a01ecf0d4fb5f345f33992c6ccbd6349824fb42 567be21bddb474a96c199330070fcbb82e8ab9f9 1ddc0320d85708fcec503400d730c787ae9cbc83 eec058d2c76bfa135b1e10eb13723840a661a032 04279437b6f9367261c462c685cc47e8bafe9bc5 c1bfa9484102fbdf2d1993b2379c2fa3dc0b1b83
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.
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.
Assuming Point 7 to be expected behaviour for now.Verifed response code for provider/provider_accounts pool/pool_family.
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